GDI is responsible for tasks such as drawing lines and curves,
rendering fonts and
handling palettes. It is not directly
responsible for drawing windows, menus, etc.; that task is reserved
for the user subsystem, which resides in user32.dll and is built atop GDI.
GDI is similar to Macintosh's QuickDraw and GNOME/GTK's GDK/Xlib.

Perhaps the most significant capability of GDI over more direct
methods of accessing the hardware is its scaling capabilities, and
abstraction of target devices. Using GDI, it is very easy 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 all What You See Is What You
Get applications for Microsoft Windows.

Simple games which do not require fast graphics rendering use
GDI. However, GDI cannot animate properly (no notion of
synchronizing with the framebuffer) and lacks rasterization for 3D. Modern games tend to
use DirectX or OpenGL, which give programmers
the capabilities to use features of modern hardware.

Contents

Technical
details

A Device Context (DC) is used to define the attributes
of text and images that are output to the screen or printer. The
actual context is maintained by GDI. A handle to the Device Context
(HDC) is obtained before output is written and then released after
elements have been written.

A DC, like most GDI objects, is opaque - its data cannot be
accessed directly, but its handle can be passed to various GDI
functions that will operate on it, either to draw an object, to
retrieve information about it, or to change the object in some
way.

GDI+

With the introduction of Windows XP, GDI was deprecated in favor of
its successor, the C++ based GDI+ subsystem. GDI+
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 ARGB values to represent color. Use of
these features is apparent in Windows XP's user interface and
several of its applications such as Microsoft Paint, Windows Picture and Fax
Viewer, Photo Printing Wizard, My Pictures Slideshow
screensaver, and their presence in the basic graphics layer greatly
simplifies implementations of vector-graphics systems such as Flash or SVG. The GDI+ dynamic library
can be shipped with an application and used under older versions of
Windows.

Because of the additional text processing and resolution
independence capabilities in GDI+, text rendering is nearly an
order of magnitude slower than in GDI.[1] Chris
Jackson, an application compatibility expert working for Microsoft
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.

Windows
Vista

In Windows Vista, all Windows applications including GDI and
GDI+ applications run in the new compositing engine, Desktop Window Manager which is
built atop the Windows Display Driver
Model. The GDI render path is redirected through DWM and GDI is
no longer hardware-accelerated by video card driver. [2][3]
However, due to the nature of desktop composition (internal
management of moving bitmaps and transparency and anti-aliasing of
GDI+ being handled at the DWM core), operations like window moves
can be faster or more responsive because underlying content does
not need to be re-rendered by the application.[2]

Windows 7

GDI hardware acceleration for blitting operations is
incorporated in Windows
7, which features Windows Display Driver Model
v1.1. This allows the DWM engine to use local video memory for
compositing, thereby reducing system memory footprint and
increasing the performance of graphics operations. As of November
2009, both ATI
and Nvidia have released WDDM
v1.1 compatible video drivers. Unlike Direct2D, most primitive operations are not
hardware-accelerated.

Relation between GDI and
GDI printers

GDI
printers

A GDI printer or a Winprinter (similar to a Winmodem)
is a print
processor that uses software to do all the print processing
instead of requiring the printer hardware to do it. It works by
rendering an image to a bitmap on the host computer and then
sending the bitmap to the printer.

This allows low-cost printers to be built by printer
manufacturers, because all the page composition is done in
software. Usually, such printers do not natively support a page
description language such as PostScript or XPS. A Winprinter uses GDI to prepare the
output, which is then passed to the printer driver (usually
supplied by the manufacturer) for further processing and only
afterwards to the printer itself.[4]

In general, usually, the lowest-cost printers are GDI devices.
Most manufacturers also produce more flexible models that add PCL compatibility, or PostScript, or both. In
most cases it is only the very lowest-cost models in any given
manufacturer's range that are GDI-only.

Compare how GDI printers rely on this 2-way constant
communications between the PC and the printer to leach off the PC's
processor, as opposed to standard printers, which send a completed
file to a standard printer for it to create. Thus, a GDI printer
cannot create a document without a PC attached. This is why a GDI
printer won't print when attached to a standard stand-alone print
server, though some manufacturers have created a solution to this
problem by making print servers that are capable of processing
data. Another solution would be to physically attach the GDI
printer to a PC or file server, and share the printer via this
connection (though the PC must be constantly left on for the GDI
printer to be accessible).

Limitations

GDI overflow in Internet Explorer 7 prevents the graphical
elements of the browser tabs from drawing correctly, and the
address bar incorrectly appears by itself in the top-left corner of
the desktop display area. In these example screenshots,
approximately 49 windows were opened at the same time, using
Windows XP with Service Pack 3 and Internet Explorer 7.

Each time a window is opened, it 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. [5][6] The
total available GDI objects varies from one version of Windows to
the next: Windows 95, 98, and Millennium had a limit of 1,200 total
objects; Windows 2000 has a limit of 16,384 objects; and Windows
XP, Vista, and Windows 7 have a configurable limit (via the
registry) that defaults to 10,000 objects. [7][8]

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. 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 hard-reset of the system, since it prevents
core system programs from functioning.

For example, forcing a frozen process to end using the Task
Manager normally makes an "Are you sure" alert window appear. With
no free GDI, Windows beeps an error and the alert choice does not
appear, so the GDI-overflowing processes cannot be terminated.

Sometimes a single application can consume the entire free
desktop heap memory. There is a tool from Microsoft
called Desktop Heap Monitor which can show which application
consumes what percent of the desktop heap [9]