Gdi windows что это за программа

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. It was superseded by DirectDraw API and later Direct2D API.^{[citation needed]} 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: Mac OS had QuickDraw, and Linux and Unix have X Window System core 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.

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]

GDI was present in the initial release of Windows. MS-DOS programs had 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 a 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]

On Windows 3.1x and Windows 9x, GDI can use Bit blit features for 2D acceleration, if suitable graphics card driver is installed.^[3]

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.^[4]

Because of the additional text processing and resolution independence capabilities in GDI+, the CPU undertakes text rendering.^[5] The result is an order of magnitude slower than the hardware-accelerated GDI.^[6] 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.

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.^[7][8][9] 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.^[8]

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.^[10]

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.^[11][12] 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.^[11]

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.

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.^[13] Many applications are also incorrectly coded and fail to release GDI objects after use, which further adds to the problem.^[14] 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).^[15][16] Windows 8 and later increase the GDI object limit to 65,536 per user login 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.

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.^[17]

• WinG
• Microsoft Windows library files

• 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 Archived 2009-02-04 at the Wayback Machine
• IGDI+ — Delphi Open Source GDI+ library.

Если вы видите это сообщение, значит, произошла проблема с загрузкой файлов в стилей (CSS) нашего сайта. Попробуйте сбросить кэш браузера (Ctrl+F5).
Если это не поможет, а вы находитесь в регионе, где возможны ограничения интернет-трафика с российских серверов — воспользуйтесь VPN.

По своей сути GDI+ (иначе Graphics Device Interface) представляет собой один из 3-х компонентов, который совместно с ядром, а также Windows API, образует общий пользовательский интерфейс, который мы и видим, отвечает за графику. Частенько его называют оконный менеджер GDI. Также GDI+ используется в максимально упрощенных играх, для которых шустрая графика не важна и они прибегают к возможностям GDI. Видео, на котором при запуске Windows проскальзывает компонент GDI+ johnn­y marr [27.6K] 9 лет назад  GDI+ является библиотекой, пришедшей на смену библиотеке GDI (графическое ядро прежних версий Windows- до XP). Основной целью создания GDI+ был перенос (возможность использования) приложений на 64-битных платформах. Использование GDI+ уже встроено в Windows XP. Чтобы приложения могли использоваться на других, более ранних версиях, нужно установить дистрибутив gdiplus_dnld.exe. найти его можно по ссылке. Иерархию классов GDI+ можно посмотреть в таблице: Картинка с сайта: www.bolshoyvopros.ru Людви­го [148K] 9 лет назад  GDI можно назвать подсистемой, которая составляет интерфейс пользовательский, или оконный менеджер Microsoft Windows. Он представляет графические изображения, а также отвечает за их передачу на такие носители, как мониторы и принтеры. Иначе говоря, та графика, которую мы видим, -это и есть работа GDI. Сейчас же ее совершенствуют, потому она получила свой плюсик. Вот ее пример: Letuz­assy [368] 10 лет назад  GDI+: графика нового поколения (Class-based API) вроде так) Знаете ответ?

10.1. Определение контекста отображения и устройства

Интерфейс графических устройств операционной системы Microsoft Windows (в дальнейшем — просто GDI) предназначено для взаимодействия приложений Windows с графическими устройствами ЭВМ. Использование такого «промежуточного уровня» между приложением Windows и устройством позволяет решить следующие проблемы:

1. Средствами GDI можно вывести любой текст, изображение, форматирование на любое устройство ЭВМ, которое при подключении к операционной системе Windows имеет для неё собственный драйвер. Следовательно, единообразно можно вывести информацию на любое устройство: принтер, монитор, графопостроитель, в локальную или глобальную сеть, не занимаясь «прямым программированием устройств» (как это Вам пришлось осуществлять бы в MS-DOS);
2. Средствами GDI осуществляется вывод не на физическое, а на «логическое» устройство. Это значит, что Вы, например, можете задать вывод картинки с 16 млн. цветов на монитор, поддерживающий только 256 цветов. Вывод изображения на «логический монитор» средствами GDI будет производиться единообразно, будут задействованы все 16 млн. цветов. Однако драйверы видеокарты и монитора учтут свои ограничения на имеющийся цветовой диапазон, и «автоматически» преобразуют картинку с 16 млн. цветами в картинку с 256 цветами. Драйвер принтера вообще преобразует эту картинку в двухцветное изображение, напечатав полутона в виде растра («мозаики»);
3. Имея параметры физических устройств, подключённых ЭВМ, «ниже среднего уровня», Вы, тем не менее, можете создавать программы для любых «продвинутых устройств» ЭВМ, отсутствующих на Вашем компьютере. Более того, Вы можете осуществлять программирование устройств, ещё не созданных для данных ЭВМ — необходимо только, чтобы эти устройства были, во-первых, совместимые с ЭВМ на аппаратном уровне, а во-вторых, разработка их драйверов должна укладываться в стандарты, по которым создаются драйверы для указанного семейства устройств и стандартами Microsoft в написании драйверов к операционной системе Windows;
4. Такая ситуация, когда приложение запрашивает у Windows одно, а получает другое, возникает не только при работе с цветом. Приложение может запросить для вывода шрифт, описав его характеристики, а GDI подберёт к выводу наиболее подходящий (с его точки зрения) шрифт, соответствующий описанию, и предоставит его приложению для вывода. Вначале такой подход обескураживает, но затем Вы начинаете понимать, что такой способ является единственным способом заставить работать программу Windows на любом оборудовании, любой аппаратной части. В самом деле, шрифтом, которым выводятся данные на экран, часто нельзя выводить данные на принтер — его может не быть в списке поддерживаемых шрифтов для данной модели принтера. И что же, из-за этого не выводить данные на принтер?…

Из чего состоит интерфейс GDI с точки зрения приложения?

Прежде всего, это контекст отображения и инструменты для рисования. Контекст является как бы листом бумаги, на котором приложения рисует графику и текст. Инструменты рисования — это перья, кисти (а также шрифты, курсоры, иконки, и даже целые графические изображения), с помощью которых создаётся изображение на устройстве. Если же говорить более точно, то контекст — это структура данных, описывающая устройство отображения. В этой структуре хранятся различные характеристики устройства и набор инструментов рисования, выбранные по-умолчанию. Приложение может выбирать в контексте отображения различные инструменты. Но собственно в функциях рисования изображений и вывода текста эти инструменты не указываются — они «наследуются» из контекста.
Приложение сможет создать контекст отображения не только для экрана монитора или окна, но и для любого другого графического устройства вывода, например, принтера и графопостроителя. Можно создать контекст изображения для метафайла. Метафайл — это обычный файл или файл в памяти, в котором хранится последовательность команд интерфейса GDI. Приложение может осуществить вывод графической информации в метафайл, а затем вывести содержимое метафайла на любое устройство вывода.

Изучение GDI мы начнём с подробного описания контекста изображения и его атрибутов. Собственно схема взаимодействия контекста и драйверов устройства показана на рисунке 10.1.

Картинка с сайта: intuit.ru

Рис.
10.1.
Ввод-вывод данных через контекст устройства

Также во вводной части необходимо отметить, что контекст — очень ресурсоёмкая структура данных, которая, к тому же, не освобождается при закрытии приложения, его вызвавшего. Поэтому, если создать множество контекстов, а затем не удалить (или не освободить) эти контексты, Ваша система как бы «ни с того ни с сего» станет работать нестабильно, и это может привести к краху операционной системы и её перезагрузке. Поэтому применяем следующие правила:

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

10.2. Правила работы с контекстом

10.2.1. Работа с контекстом отображения

Как правило, приложения выполняют свою работу по рисованию содержимого окна во время обработки сообщения Windows WM_PAINT, хотя часто требуется рисовать и во время обработки других сообщений. В любом случае приложению нужно придерживаться следующей последовательности действий:

• получение или создание контекста отображения;
• установка необходимых атрибутов в контексте отображения;
• выполнение операций рисования;
• освобождение либо удаление контекста отображения.

Последнее действие (освобождение либо удаление контекста отображения) должно быть обязательно выполнено. Самый простой способ полностью нарушить работоспособность Windows — забыть освободить полученный контекст отображения или забыть удалить созданный контекст отображения или устройства.

Так как контекст отображения — «самый критичный» ресурс Microsoft Windows, его необходимо освобождать сразу, как только в нём отпадает необходимость. Операционная система Microsoft Windows выполняет кэширование обычного контекста отображения, причём кэшируется только пять контекстов (информация для Microsoft Windows 3.11). Если операционная система не может удовлетворить запрос какого-либо приложения на выделение контекста отображения, вся операционная система окажется в критическом состоянии, из которого есть только один выход — перезагрузка Windows.

10.2.2. Типы контекстов отображения

Можно выделить следующие типы контекста отображения:

• общий контекст отображения (common display context);
• контекст отображения класса окна (class display context);
• личный контекст отображения (private display context);
• родительский контекст отображения (parent display context);
• контекст отображения для окна (window display context);
• контекст физического устройства (device context);
• информационный контекст (information context);
• контекст для памяти (memory device context);
• контекст для метафайла (metafile context);

Каждый из перечисленных выше контекстов имеет свои особенности и своё назначение.

10.2.3. Общий контекст отображения

Этот контекст используется чаще всего, поэтому для ускорения доступа к нему Windows использует кэширование. Для получения общего контекста отображения приложение должно вызвать функцию BeginPaint (при обработке сообщения WM_PAINT ) или GetDC (при обработке других сообщений). При этом перед регистрацией класса окна в структуре WNDCLASS не должны использоваться значения CS_OWNDC, CS_PARENTDC или CS_CLASSDC. Например:

wc.style = 0;

Функция BeginPaint возвращает контекст отображения для окна hwnd:

HDC WINAPI BeginPaint( HWND hwnd, PAINTSTRUCT FAR *lpps);

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

Назначение полей структуры PAINTSTRUCT смотри в приложении № I к данной лекции (п. 10.4).

Контекст отображения, полученный с помощью функции BeginPaint, необходимо освободить перед завершением обработки сообщения WM_PAINT, вызвав функцию EndPaint с теми же параметрами:

void WINAPI EndPaint( HWND hwnd, PAINTSTRUCT FAR *lpps);

Примечание: функции BeginPaint и EndPaint можно использовать только внутри обработчика сообщения WM_PAINT. Если приложению Microsoft Windows требуется рисовать при обработке других сообщений, оно должно получить контекст отображения с помощью функции GetDC и освободить функцией ReleaseDC ;

Функция GetDC возвращает контекст отображения для окна с идентификатором hwnd:

HDC WINAPI GetDC( HWND hwnd );

Функция ReleaseDC освобождает контекст изображения hdc, полученный для окна hwnd:

int WINAPI ReleaseDC( HWND hwnd, HDC hdc );

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

Understanding GDI+ Window (Ccc.Exe): An In-Depth Analysis

Graphics Device Interface (GDI) and its enhanced version, GDI+, are essential components of the Microsoft Windows operating system. They provide a set of functions that allow applications to render their graphics and manage visual elements. One particularly noteworthy entity within the realm of GDI+ is the Ccc.exe process, often referred to in the context of graphic applications and hardware acceleration.

What is Ccc.exe?

Ccc.exe is an executable associated with the Catalyst Control Center (CCC), a utility developed by AMD (Advanced Micro Devices) that manages graphics drivers and settings for graphics rendering. When you install AMD graphics drivers, the Catalyst Control Center is often bundled with it, allowing users to optimize their video card settings, manage display settings, and enhance overall graphics performance.

The presence of Ccc.exe on your system indicates that you have installed AMD graphic drivers and that you can fully utilize the features provided by the Catalyst Control Center. Primarily, this process is responsible for the management of graphics settings and adjustments, guaranteeing that applications communicate effectively with the GPU (Graphics Processing Unit).

The Role of GDI+ in Windows

GDI+ stands for Graphics Device Interface Plus, an upgraded version of GDI that introduces advanced features for rendering graphics. While the original GDI was primarily designed for basic drawing operations, GDI+ consolidates rendering and graphical operations, allowing for higher quality output and more complex graphics tasks.

Key Features of GDI+

1. Advanced Graphics Rendering: GDI+ supports anti-aliasing, gradient fills, and transparency, which helps in rendering smoother graphics.
2. Support for Various Image Formats: It provides functionality for handling multiple widely-used image formats like JPEG, PNG, BMP, and GIF.
3. Fonts and Text Rendering: GDI+ includes enhanced capabilities for text rendering and supports TrueType fonts directly.
4. Clipping Regions: GDI+ allows defining complex clipping regions, which can be useful for creating sophisticated UI elements.
5. Drawing Shapes: The ability to draw complex shapes and paths adds design flexibility.

These capabilities position GDI+ as a crucial layer for developers needing to create visually dynamic applications on the Windows platform.

Interplay Between GDI+ and Ccc.exe

The interaction between GDI+ and Ccc.exe is vital for effective graphics rendering. When an application requests to render graphics, the GDI+ API queries the system settings managed by the AMD Catalyst Control Center. This means Ccc.exe plays a crucial role in ensuring that the right settings (such as hardware acceleration, refresh rates, and other performance tweaks) are applied.

How Ccc.exe Improves GDI+ Performance

By leveraging the capabilities of GDI+, Ccc.exe impacts performance in several ways:

• Hardware Acceleration: Ccc.exe can enable or adjust hardware acceleration settings, which means that the GPU can take over tasks that would normally be handled by the CPU. This transition reduces the processing load on the CPU and improves rendering speed and performance.
• Configuration Profiles: Users can create different configuration profiles for various applications, allowing GDI+ to optimize settings based on the demands of specific games or programs.
• Power Management: Ccc.exe manages power consumption through dynamic frequency scaling, helping maintain a balance between performance and energy usage.

Common Issues Associated with Ccc.exe

While Ccc.exe plays a pivotal role in managing graphics settings, it is not without its share of complications. Users sometimes encounter issues related to the Catalyst Control Center and the associated executable, Ccc.exe.

Issues and Symptoms

1. High CPU Usage: Some users report that Ccc.exe may use an unusually high amount of CPU resources. This can lead to decreased performance in other applications, particularly when running graphics-intensive tasks.
2. Application Crashes: In certain cases, applications dependent on GDI+ may face unexpected crashes or freezes, often triggered by incorrect settings in Ccc.exe.
3. Slow Performance: If Ccc.exe is misconfigured or if the graphics driver is outdated, users may experience sluggish performance in graphics rendering tasks.
4. Error Messages: Common error messages include “Ccc.exe failed to start” or “Catalyst Control Center is not compatible with the current driver version.”

Troubleshooting Tips

If you face issues with Ccc.exe or the Catalyst Control Center, consider the following steps:

1. Update Drivers: Ensure that you have the latest AMD graphics drivers installed. Manufacturers frequently release updates that fix bugs and improve compatibility.
2. Reinstall Catalyst Control Center: If the CCC is malfunctioning, uninstalling and then reinstalling might resolve underlying issues.
3. Adjust Settings: Sometimes, reverting changes made in CCC or resetting to default settings can rectify performance issues.
4. Check System Resources: Utilize Task Manager to monitor Ccc.exe and other processes for unusual CPU or memory consumption. This can sometimes highlight conflicts with other software.
5. Run System Maintenance: Regularly perform system checks, cleanups, and updates to ensure all components are functioning optimally.

The Importance of Security in Executables like Ccc.exe

Security is a pressing concern for users of any executable file on their systems. Ccc.exe, while legitimate, can sometimes be mimicked by malware seeking to exploit a user’s machine.

Identifying Legitimate Ccc.exe

1. Location Verification: The legitimate Ccc.exe is typically found in the following directory: C:Program Files (x86)ATI TechnologiesATI.ACECore-Static. If it resides in any other location, there is a strong possibility that it is malicious.
2. Digital Signature Check: Right-click the Ccc.exe file, go to Properties, and Tabbing to Digital Signatures. It should be signed by AMD. If not, it might be a counterfeit application.
3. Antivirus Scan: Run a scan with a trusted antivirus application to ensure the executable is not harboring any malicious software.

How GDI+ and Ccc.exe are Evolutionary Forces in Graphics Technology

The development of GDI+ and the Ccc.exe process reads like a narrative of increasing sophistication in digital graphics rendering. As user demands grow for more intricate visual experiences, these technologies work symbiotically to deliver those needs.

Embracing Future Technologies

1. DirectX Integration: Current graphics applications now often utilize DirectX alongside GDI+, enabling applications to maximize the capability of modern GPUs. This integration may influence how Ccc.exe manages various forms of rendering.
2. 3D Graphics and Augmented Reality: As the realms of gaming and interactive applications expand into 3D and AR, technologies like GDI+ may need to evolve beyond their traditional 2D graphics roles.
3. Evolving Hardware Capabilities: With ongoing advancements in hardware technology (such as AI integration in GPUs), Ccc.exe may also adapt to manage new performance characteristics and enable features related to machine learning tasks.

The Future of GDI+ and Ccc.exe

The ongoing evolution of software and hardware landscapes means that both GDI+ and Ccc.exe will need to adapt to new paradigms. The growing significance of cloud computing, virtualization, and robust online gaming and graphic applications will surely influence future iterations of these technologies.

Conclusion

Understanding the role of GDI+ and the Ccc.exe process is critical for users who want to harness the full potential of their AMD graphics hardware. From ensuring optimal settings to troubleshooting performance issues, a comprehensive grasp of these components can enhance both the usability and functionality of applications reliant on high-grade visual rendering.

By keeping tabs on updates, ensuring security, and being aware of the interaction between these crucial elements, users can optimize their experience in the dynamic landscape of digital graphics. Whether you are a gamer, a developer, or simply a casual computer user, knowledge of how GDI+ and Ccc.exe work can significantly influence your graphics experience on Windows systems. As technology advances, these components will likely continue to evolve, paving the way for even more impressive graphical capabilities in the future.

Материал из РУВИКИ — свободной энциклопедии

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

Для определения атрибутов текста и изображения, которые выводятся на экран или принтер, используется программный объект под названием «контекст устройства» (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 была полностью переписана с нуля заново, причём на C++ (по слухам, у Microsoft тогда не было компилятора этого языка и они использовали cfront). API для приложений не изменился (кроме добавления кривых Безье), для драйверов — обёртки на языке Си вокруг реализованных на C++ внутренностей (вроде 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 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