The Graphics Device Interface (GDI) is a Microsoft Windows application programming interface and core operating system component responsible for representing graphical objects and transmitting them to output devices such as monitors and printers.
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. Other systems have components that are similar to GDI, for example Macintosh's QuickDraw and GTK's GDK/Xlib.
Perhaps the most significant capability of GDI over more direct methods of accessing the hardware are its scaling capabilities, and its abstract representation 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 that do not require fast graphics rendering use GDI. However, GDI is relatively hard to use for advanced animation, and lacks a notion for synchronizing with individual video frames in the video card, lacks hardware rasterization for 3D, etc. Modern games usually use DirectX or OpenGL instead, which give programmers the capabilities to use features of modern hardware.
Contents |
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.
With the introduction of Windows XP, GDI was deprecated in favor of its successor, the C++ based GDI+ subsystem, i.e. for applications written in C++. 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.
GDI+ is included with all versions of Windows from Windows XP. The GDI+ dynamic library can also be shipped with an application and used under older versions of Windows from Windows 98 and Windows NT 4.0 onwards.[1]
Because of the additional text processing and resolution independence capabilities in GDI+, text rendering is performed by the CPU [2] and it is nearly an order of magnitude slower than in hardware accelerated GDI.[3] 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.
The Microsoft .NET class library provides a managed interface for GDI+ via the System.Drawing namespace.
GDI+ is similar (in purpose and structure) to Apple's Quartz 2D 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 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 the video card driver. [4][5] 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.[4]
Windows 7 includes GDI hardware acceleration for blitting operations. This improves GDI performance using new features in the 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. Most primitive GDI operations are still not hardware-accelerated, unlike Direct2D. As of November 2009, both ATI and Nvidia have released WDDM v1.1 compatible video drivers.
GDI+ continues to rely on software rendering in Windows 7.[6]
A GDI printer or Winprinter (analogous to a Winmodem) is a printer designed to accept output from a host computer running the GDI under Windows. The host computer does all print processing: the GDI software renders a page as a bitmap which is sent to a software printer driver, usually supplied by the printer manufacturer, for processing for the particular printer, and then to the printer.[7] The combination of the GDI and the driver is bidirectional; they receive information from the printer such as whether it is ready to print, if it is out of paper or ink, and so on.
Non-GDI printers require hardware, firmware, and memory for page rendering; a GDI printer uses the host computer for this, making it cheaper to manufacture than a similar but non-GDI printer. Some manufacturers produce essentially the same printer in a version compatible with a printer control language such as PCL or PostScript, and a cheaper GDI-only version. In most cases only the very lowest-cost models in any given manufacturer's range support only GDI.
A printer with its own control language can accept input from any device with a suitable driver; a GDI printer requires a PC running Windows, and is not compatible with other hardware and operating systems. In general GDI printers are not compatible with hardware print servers, although some servers have built-in processing capability making them compatible with specified GDI printers. 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 have been written which make some GDI printers compatible with non-Microsoft operating systems such as Linux, but there is no guarantee that any particular GDI printer will be supported.[7]
| 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. [8][9] 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 per process (but a theoretical maximum of 65,536 for the entire session). [10][11]
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 ironically 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 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,[12] which can show which application consumes what percent of the desktop heap.
Direct2D and DirectWrite were designed to replace GDI/GDI+ and Uniscribe, respectively, for screen-oriented rendering and were shipped with Windows 7 and Windows Server 2008 R2, as well as Windows Vista and Windows Server 2008 (with Platform Update installed).
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||