Как работает gdi windows
Интерфейс графических устройств Windows ( GDI - Graphic Device Interface ) представляет собой виртуальное графическое устройство для всех приложений независимо от конкретных аппаратных средств, из которых состоит компьютер. GDI является неотъемлемой частью ядра операционной системы, контролирующей и обеспечивающей все операции графического вывода приложений Windows .
Корпорация Microsoft создала GDI , чтобы отделить графические операции от фактически используемого оборудования. Для программиста предоставлены графические функции высокого уровня абстракции, которые обеспечивают одинаковые результаты выполнения независимо от используемого оборудования. От разработчиков аппаратных средств требуется обеспечить поставку и драйверов (программ управления оборудованием на низком уровне) для естественного подключения их к функциям GDI .
Пользовательская сторона GDI (пользователь GDI - это разработчик приложения) реализована с помощью контекста устройства. Контекст графического устройства - это конкретная настройка GDI на выполнение графических операций. Управление контекстом устройства обеспечивается MFC -классом CDC . Объект, созданный с помощью этого класса, содержит все необходимые настройки GDI , установленные по умолчанию или пользователем (разработчиком приложения). Фактически экземпляр класса CDC или производных от него классов и представляет собой контекст устройства, олицетворяя собой все настройки GDI .
Контекст устройства способен обеспечить вывод изображений на любое внешнее устройство, будь то экран, принтер, графопостроитель и т.д. При этом используются одни и те же функции GDI . Для отображения изображения на экране приложению необходимо иметь контекст устройства экрана, для отображения на принтере - контекст другого устройства - принтера.
Контексты экрана и принтера называются физическими контекстами или контекстами вывода. Существуют еще два контекста устройства: растр и метафайл. Растр является тем же контекстом устройства, содержащим набор пикселов и по своей структуре готовый для подключению к физическому контексту, но пока хранящийся в памяти. Метафайл является набором готовых инструкций, способных создать графическое изображение перед подключением к физическому контексту.
Контекстов устройства, как экземпляров класса CDC , одновременно может быть создано в приложении несколько и все они будут храниться в памяти готовыми для подключения, но только один из них в текущий момент времени может быть связан с конкретным физическим устройством вывода информации. т.е. только один может служить физическим контекстом ( контекстом вывода ). Существуют наследники класса CDC , создающие контексты в частных случаях, например, CPaintDC, CClientDC . Поскольку CDC является базовым классом для всех других классов контекста устройства, все его методы доступны независимо от того, с каким классом контекста устройства мы работаем в данный момент.
Объекты контекста устройства, а равным образом и все различные объекты рисунка, классифицируются в Windows как ресурсы. Операционная система может иметь ограниченное количество таких ресурсов и они могут исчерпаться, если приложение занимает их и вовремя не освобождает. Эта потеря известна как утечка ресурсов и во многом подобна утечке памяти, поскольку тоже в конечном итоге приводит к блокировке системы.
Чтобы избежать утечки подобных ресурсов, удобнее создавать их как локальные на стеке в пределах тех функций, где они будут использоваться. Соответственно при выходе из такой функции ресурс автоматически освобождается. Единственное реальное исключение, - когда объект контекста устройства создается самой Windows и передается в функцию обработки события в качестве параметра pDC. Например
Некоторые свойства (атрибуты) контекста устройства представляют собой простые типы данных, встроенные прямо в контекст устройства. Но большинство графических атрибутов контекста устройства представляют собой сложные данные типа структур или даже классов со своими функциями членами. Экземпляры этих классов называются графическими атрибутами контекста устройства. Экземпляры этих классов нужно создавать, настраивать и подключать к контексту устройства, чтобы они должным образом влияли на графический вывод.
Поддержка цветов в GDI
Базовым типом данных Windows для хранения цветов является структура COLORREF . Проще всего задать цвет при помощи макрокоманды RGB , которой передаются три числовых значения от 0 до 255. Например:
Такой способ задания цвета в GDI называется логическим цветом. Но это только наше пожелание, а реальное отображение цвета определяется способностью аппаратного устройства. Монитор с высокой разрешающей способностью, расчитанный на отображение 24-битной или 32-битной глубины цвета не будет иметь никаких расхождений между логическим и физическим цветом. Для более слабых мониторов GDI будет сам осреднять цвета, подбирая наибольшее сходство между логическим (запрашиваемым) и физическим (реально отображаемым) цветом. Аналогичный процесс происходит и для принтеров.
Таким образом, если, например, красный цвет запрошен у физического устройства, способного его отобразить, то все нормально - мы получим то, что требовалось. Но если физическое устройство не способно отобразить запрошенный цвет, то оно применит самый близкий (с точки зрения GDI ). Для черно-белых принтеров GDI стремиться подобрать наиболее близкие цвета через оттенки серого, что иногда никуда не годится. Чтобы решить эту проблему, можно просто не запрашивать недоступные цвета. Чтобы выяснить, сколько цветов поддерживает конкретное физическое устройство, нужно обратиться к функции контекста этого устройства
Для цветных мониторов система предоставляет стандартную палитру из 20 цветов, на основании которой формируются все другие цвета.
Класс контекста устройства CDC имеет множество методов, но существуют три основных направления применения этих методов для управления функциями GDI :
- Текст
- Векторная графика
- Растровая графика
Для каждого из них в GDI существуют свои функции управления, потому что на уровне драйверов устройств каждый из этих наборов операций имеет свою реализацию и выполняется по разному.
В 2016 году, когда большинство программ выполняются в песочницах, из которых даже самый некомпетентный разработчик не сможет навредить системе, странно сталкиваться с проблемой, о которой дальше пойдет речь. Если честно, я надеялся, что она ушла в далекое прошлое вместе с Win32Api, но недавно я с ней столкнулся. До этого я лишь слышал жуткие байки старых более опытных разработчиков, что такое может быть.
Проблема
Утечка или использование слишком большого числа GDI объектов.
Симптомы:
Почему?
Как исправлять?
Если Вы живете в аккуратном управляемом CLR’ом мире, то вероятность 9 из 10, что у Вас в приложении обычная утечка памяти. Проблема хоть и неприятная, зато довольно обыденная и есть по меньшей мере дюжина отличных инструментов для ее поиска. Подробно останавливаться на этом не буду. Вам лишь будет нужно использовать любой профилировщик, чтобы посмотреть, не увеличивается ли число объектов-оберток над GDI ресурсами, это: Brush, Bitmap, Pen, Region, Graphics. Если это действительно так, то Вам повезло, можете закрывать вкладку со статьей.
Если не нашлась утечка объектов-оберток, то значит у Вас в коде есть прямое использование функций GDI и сценарий, при котором они не удаляются.
Что Вам будут советовать другие?
Официальное руководство от Microsoft или другие статьи по этому поводу, которые Вы найдете в интернете, будут советовать примерно следующее:
Найти все Create%SOME_GDI_OBJECT% и узнать, есть ли соответствующий ему DeleteObject(или ReleaseDC для HDC-объектов), а если и есть, то, возможно, существует сценарий, при котором он не вызовется.
Есть еще чуть улучшенная версия этого метода, она содержит дополнительный первый шаг:
Проект, над которым я работаю, имеет кодовую базу в более 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.
Остался последний вопрос: Как найти откуда вызываются эти методы в контексте моего кода? И здесь мне помог один хитрый трюк:
- Запустить приложение на отладку в VS.
- Найти его в Api Monitor и выбрать.
- Выбрать нужную функцию Api и поставить точку останова.
- Терпеливо нажимать “Далее”, пока она не вызовется с интересующими параметрами. (Как же не хватала conditional breakpoints из vs
- Когда дойдете до нужного вызова, перейти в VS и нажать break all.
- Отладчик VS будет остановлен в месте, где создается утекающий объект и останется лишь найти, почему он не удаляется.
Резюме:
Алгоритм длинный и сложный, в нем задействовано много инструментов, но мне он дал результат значительно быстрее, чем тупой поиск ошибок по огромной кодовой базе.
Вот он, для тех кому было лень читать или кто уже забыл с чего все начиналось, пока читал:
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, что даёт программистам доступ к большему количеству аппаратных возможностей. [Источник 1]
Содержание
Поддерживаемые операции
GDI поддерживает следующие операции рисования:
- установку определенного цвета в конкретном пикселе;
- рисование линии с учетом характеристик толщины, шаблона, цвета и стиля кисти;
- рисование дуги;
- рисование эллипса (окружности);
- рисование прямоугольника, прямоугольника со скругленными углами или многоугольника;
- рисование замкнутых фигур, заполненных сплошным цветом или шаблоном;
- рисование текста с указанным шрифтом, цветом и размером;
- перемещение прямоугольника по экрану, возможно, с изменением размеров;
- ограничение операций рисования или операций перемещения в определенной области, чтобы не затрагивать изображение за пределами этой области. [Источник 2]
Контекст устройства
Контекст устройства (Device context) - это то место, куда рисуется графика, плюс средства рисования графики. Можно получить контекст устройства окна и после этого рисовать что-то в этом окне. Можно получить контекст устройства принтера и рисовать фигуры на печатаемой странице. Контекст устройства позволяет использовать кисти (brushes), перья (pens), картинки (bitmaps) для вывода графики.
Получение контекста устройства окна
Для получения контекста устройства окна используется описатель окна (HWND). Контекст устройства представлен в программе переменной типа HDC - переопределённый указатель на void. Для получения контекста устройства окна используется функция getDC:
После этого можно использовать переменную hDC для рисования в окне hWnd. После завершения рисования, нужно "отпустить" контекст устройства с помощью функции ReleaseDC .
Функция Rectangle принимает следующие аргументы: контекст устройства, координаты левого верхнего угла, координаты правого нижнего угла.
Функция TextOut принимает аргументы: контекст устройства, координаты левого верхнего угла текста, текстовая строка, количество символов в текстовой строке.
Функция Release принимает аргументы: окно, контекст устройства.
Вывод графики в нескольких окнах
Когда заполняется структура WNDCLASS, чтобы зарегистрировать класс окна программы в Windows, заполняется поле style:
Данное поле задаёт стиль класса окон. Значение CS_OWNDC говорит, что для каждого окна данного класса будет создан свой контекст устройства. [Источник 3]
Типы контекста устройства
В GDI существуют пять типов контекста устройства:
- связанный с дисплеем (Display DC)
- принтером (Printer DC)
- контекст виртуального устройства в памяти (Memory DC)
- контекст Metafile DC
- специальный вид контекста - информационный (Information DC).
Первые четыре типа контекста устройства - display, printer, memory и metafile предоставляют унифицированный интерфейс для вывода графической информации на разнотипные устройства, освобождая приложение (и его разработчика) от необходимости заботится о том, куда именно производится вывод графики. Информационный контекст для вывода графики не используется, он служит исключительно для получения информации о параметрах и поддерживаемых режимах устройства, с которым связан.
В чем отличие первых четырех типов контекста? Это можно понять из их названий - Display DC служит для вывода на экран, Printer DC для печати на принтер или графопостроитель, Memory DC служит для создания растровых изображений в памяти с возможностью быстрого их копирования в другие типы контекстов (и обратно), Metafile DC нужен для вывода графики в метафайл. Метафайл - это хранилище последовательности команд GDI, каждая из которых описывает одну графическую функцию. В отличие от растровых файлов, хранящих графическую информацию непосредственно в виде массива пикселов, метафайл ее хранит в виде последовательности команд, которая создает результирующий рисунок. [Источник 4]
Регионы Windows
Для повышения эффективности работы Windows оперирует с несколькими типами регионов. Идея заключается в том, чтобы рисовать именно в той части окна, которая требует обновления, а не перерисовывать все окно. Также регионы позволяют отсекать вывод той части графической информации, которая не может быть отображена в данный момент. Вообще полное изучение всей иерархии регионов и их взаимодействия является непростой задачей, требующей пространного из ложения1. В то же время приведенное ниже упрощенное описание достаточно для понимания работы большинства функций Win32 GDI.
Обновляемый регион (update region), или, как его тоже иногда называют, недействительный регион (invalid region) — это часть окна, которая требует обновления после возникновения тех или иных событий.
Видимый регион (visible region) — та часть окна, которую в данный момент видит пользователь. Система изменяет видимый регион окна и в том случае, когда окно изменяет размеры, и в том случае, когда перемещение другого окна либо закрывает часть данного окна, либо открывает закрытую прежде часть.
Регион отсечения (clipping region) ограничивает область, внутри которой система разрешает отображение графической информации. Когда приложение получает контекст устройства при помощи функции BeginPaint, система устанавливает регион отсечения путем пересечения видимого региона и обновляемого региона. Приложение может ужесточить регион отсечения и ввести дополнительные ограничения при помощи вызова функции SetWindowRgn, SelectClipPath или SelectClipRgn.
Если при создании окна функцией CreateWindow был использован стиль WS_CLIPCHILDREN или WS_CLIPSIBLINGS, то это вносит дополнительные правила в определение видимого региона, исключая из него любое дочернее или любые «сестринские» окна. Благодаря этому рисование не затрагивает отображаемые области таких окон.
GDI принтеры
Принтер GDI или Winprinter - это принтер, предназначенный для приема выходного сигнала от компьютера, работающий с GDI в Windows. Хост-компьютер делает всю обработку печати: программный интерфейс GDI отображает страницу как растровое изображение, которое посылается драйверу принтера программного обеспечения, как правило поставляемого производителем принтера, для обработки для конкретного принтера, а затем на сам принтер.
Non-GDI принтеры требуют аппаратные средства, оборудование и память для рендеринга страницы; принтер GDI использует ЭВМ для этого, что делает его дешевле в производстве, чем подобные Non-GDI принтеры. Некоторые производители выпускают, по сути, один и тот же принтер в версиях, совместимых с языком управления принтера, такие как PCL или PostScript, и дешевле GDI-only версия.
Принтер с собственным языком управления может принимать входные данные от любого устройства с подходящим драйвер; для принтера GDI требуется ПК с операционной системой Windows. В общем принтеры GDI не совместимы с аппаратными принт-серверами, хотя некоторые серверы имеют встроенные возможности обработки, что делает их совместимыми с принтерами GDI. [Источник 5]
Применение кода GDI+ для прорисовки графики - это более медленный процесс, чем использование файла статического изображения. Однако этот метод обеспечивает значительно большую свободу и предоставляет несколько возможностей, которые были недоступны (или являлись недопустимо сложными) в предшествующих платформах разработки веб-приложений, таких как классическая ASP. Например, можно генерировать графические элементы, которые используют специфичную для пользователя информацию, и визуализировать диаграммы и графики в соответствии с записями базы данных. [Источник 6]
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 года. [Источник 7]
Наиболее значительными преимуществами GDI по сравнению с более прямыми методами доступа к оборудованию, возможно, являются его возможности масштабирования и абстрактное представление целевых устройств. Используя GDI, можно рисовать на нескольких устройствах, таких как экран и принтер, и ожидать надлежащего воспроизведения в каждом случае. Эта возможность лежит в основе большинства приложений Microsoft Windows « Что видишь, то и получаешь ».
Простые игры, не требующие быстрой отрисовки графики, могут использовать GDI. Однако GDI относительно сложно использовать для расширенной анимации, в нем отсутствует понятие синхронизации с отдельными видеокадрами на видеокарте и отсутствует аппаратная растеризация для 3D. Современные игры обычно используют DirectX , Vulkan или OpenGL .
СОДЕРЖАНИЕ
Технические подробности
В GDI контекст устройства (DC) определяет атрибуты текста и изображений для устройства вывода, например экрана или принтера. GDI поддерживает актуальный контекст. Для генерации вывода требуется дескриптор контекста устройства (HDC). После генерации вывода ручку можно было отпустить.
GDI использует алгоритм рисования линий Брезенхэма для рисования линий с псевдонимом.
История версий
Ранние версии
GDI присутствовал в первом выпуске Windows. Программы MS-DOS до сих пор управляли графическим оборудованием, используя программные прерывания (иногда через Video BIOS ) и напрямую управляя видеопамятью . Код, написанный таким образом, предполагает, что это единственный пользователь видеопамяти, что было неприемлемо в многозадачной среде , такой как Windows. Журнал BYTE в декабре 1983 года обсуждал планы Microsoft относительно системы вывода графики на принтеры и мониторы с одним и тем же кодом в предстоящем первом выпуске Windows.
Windows XP
Хотя GDI + входит в состав Windows XP и более поздних версий, динамическая библиотека GDI + также может поставляться с приложением и использоваться в более старых версиях Windows.
Из-за дополнительных возможностей обработки текста и независимости от разрешения в GDI + центральный процессор выполняет рендеринг текста. Результат на порядок медленнее, чем GDI с аппаратным ускорением . Крис Джексон опубликовал несколько тестов, показывающих, что написанный им фрагмент кода визуализации текста может отображать 99 000 глифов в секунду в GDI, но тот же код, использующий GDI +, отображает 16 600 символов в секунду.
GDI + похож (по назначению и структуре) на подсистему Apple QuickDraw GX , а также библиотеки libart и Cairo с открытым исходным кодом .
Виндоус виста
В Windows Vista все приложения Windows, включая приложения GDI и GDI +, запускаются в новом механизме композитинга, Desktop Window Manager (DWM), который имеет аппаратное ускорение. Таким образом, GDI больше не имеет аппаратного ускорения. Из-за характера операций композиции перемещение окон может быть более быстрым или более быстрым, поскольку приложение не требует повторной визуализации базового содержимого.
Windows 7
Windows 7 включает аппаратное ускорение GDI для операций копирования в Windows Display Driver Model v1.1 . Это улучшает производительность GDI и позволяет DWM использовать локальную видеопамять для компоновки, тем самым уменьшая объем системной памяти и повышая производительность графических операций. Большинство примитивных операций GDI по-прежнему не имеют аппаратного ускорения, в отличие от Direct2D . GDI + продолжает полагаться на программный рендеринг в Windows 7.
Принтеры GDI
Принтер GDI или Winprinter (аналог Winmodem ) - это принтер, предназначенный для приема вывода с главного компьютера под управлением Windows. Главный компьютер выполняет всю обработку печати: GDI отображает страницу как растровое изображение, которое драйвер принтера получает, обрабатывает и отправляет на связанный принтер. Комбинация GDI и драйвера является двунаправленной; они получают информацию от принтера, например, готов ли он к печати или закончилась бумага.
Принтеры, которые не полагаются на GDI, требуют оборудования, микропрограмм и памяти для рендеринга страниц, в то время как принтер GDI использует для этого главный компьютер. Однако принтер с собственным языком управления может принимать ввод от любого устройства с подходящим драйвером, в то время как для принтера GDI требуется ПК под управлением Windows. Принтеры GDI можно сделать доступными для компьютеров в сети, если они подключены как общие принтеры на компьютере, который включен и работает под управлением Windows. pnm2ppa Были написаны некоторые "общие" драйверы GDI ; они стремятся сделать принтеры GDI совместимыми с операционными системами, отличными от Windows, такими как FreeBSD , но они не могут поддерживать все принтеры.
Чтобы упростить создание драйверов для Winprinters, был создан универсальный драйвер принтера Microsoft . Это позволяет поставщикам принтеров писать «минидрайверы» общего описания принтера (GPD), которые описывают возможности принтера и набор команд в виде открытого текста, вместо того, чтобы заниматься разработкой драйверов для режима ядра.
Microsoft отошла от этой модели печати с помощью спецификации Open XML Paper .
Ограничения
Каждое окно потребляет объекты GDI. По мере увеличения сложности окна с дополнительными функциями, такими как кнопки и изображения, также увеличивается использование его объекта GDI. Когда используется слишком много объектов, Windows не может рисовать больше объектов GDI, что приводит к некорректной работе программного обеспечения и зависанию и зависанию работы программы. Многие приложения также неправильно закодированы и не могут освободить объекты GDI после использования, что еще больше усугубляет проблему. Общее количество доступных объектов GDI варьируется от одной версии Windows к другой: Windows 9x имела ограничение в 1200 общих объектов; Windows 2000 имеет ограничение в 16 384 объекта; и Windows XP и более поздние версии имеют настраиваемый предел (через реестр), который по умолчанию составляет 10 000 объектов на процесс (но теоретический максимум 65 536 для всего сеанса). Windows 8 и более поздние версии увеличивают ограничение объекта GDI до 65 536 за сеанс входа в систему.
Более ранние версии Windows, такие как Windows 3.1 и Windows 98, включали программу Resource Meter, позволяющую пользователю отслеживать, какая часть общих ресурсов GDI системы используется. Этот счетчик ресурсов сам потреблял объекты GDI. Более поздние версии, такие как Windows 2000 и Windows XP, могут сообщать об использовании объекта GDI для каждой программы в диспетчере задач, но они не могут сообщить пользователю общую доступную емкость GDI.
Переполнение емкости GDI может повлиять на саму Windows, препятствуя открытию новых окон, отображению меню и появлению окон предупреждений. Ситуация может быть трудной для устранения и потенциально может потребовать принудительного сброса системы, поскольку это препятствует работе основных системных программ. В Windows 8 и 8.1 вместо перезагрузки происходит принудительный выход из системы в результате переполнения емкости GDI.
Читайте также: