Introduction: Why GDI Output For 2D Graphics Remains Relevant

First things first: if you haven't yet read 2D, Acceleration, And Windows: Aren't All Graphics Cards Equal?, please feel free to check that one out first, since it's the Part 1 to this Part 2 exploration into the history of 2D in Windows and current issues seen on high-end discrete graphics cards.

In this second part, we focus on the relevance of GDI, explain 2D graphics output more completely, and present to you our 2D benchmark (for the folks who haven't already discovered it on Tom's Hardware DE). In order to fully understand the results from that benchmark, we must first dig into some related theoretical fundamentals.

Direct2D or GDI? Or perhaps both?

Why Do We Still Test GDI in the Era of Windows 7 and Direct2D?

In the first part of this series, a number of readers speculated that, with the introduction of DirectX 10-capable graphics cards and Windows Vista, older GDI methods for 2D graphics output were rendered obsolete. The WPF (Windows Presentation Foundation), along with Direct2D, have been available to Microsoft developers for some time now. Nevertheless, there are plenty of good reasons why GDI (the Graphics Device Interface) remains unarguably meaningful and relevant, which means we must examine its behavior and performance, even for the brave new world of Windows 7. These reasons include:

The GDI continues to support older graphics cards, while Direct2D requires cards that can support DirectX 10 or better.

GDI is supported in every known version of Windows, whereas Direct2D is available only in Windows Vista and Windows 7.

Every graphics application that runs under Windows XP (and older Windows versions) uses GDI

Lots of software developers resist converting their software from older to newer APIs. Even today, many developers continue to turn to the same well-understood programming libraries, even if newer technologies are available. Converting from one library to another also means rewriting and retesting all affected code modules. Because performance improvements that result from converting from an older library to a newer one may be barely perceptible, software developers also balk at making such changes on purely economic grounds (too much time and effort for too small of a result). If you take the implementation of Direct2D in various components of Mozilla Firefox as an illustrative example, you get a sense of the industry’s leisurely pace in carrying out this conversion process. In addition, it would be a form of business suicide for many of these firms to lock the entire community of XP users out of their latest releases. All of this adds up to a single compelling observation: the GDI is likely to stick around until Windows XP no longer represents any significant component of the end-user community.

Then there are technical reasons to explain the persistence of GDI. Key GDI code modules (those that are included and invoked most often in Windows applications) aren't completely portable. Direct2D also consumes significant processing power and system resources, but can do nothing that Direct3D cannot also deliver. And those who elect to skip using Direct3D have usually considered this decision quite carefully. In addition, the GDI works independently of the output devices, such as monitors or printers, that may be in use. Thus, the same routine in a program can render graphics on a monitor, and output to a printer, thereby reducing the code (and its subsequent maintenance and error risk) by as much as one-half. Many of the most affordable printers are GDI devices nowadays, and this situation is unlikely to change any time soon, even in Windows 7, where plenty of drivers for GDI-only printers remain widely available.

Direct2D as a part of Direct3D-Output (D3D)

The Whole Is More Than the Sum of All Parts

We ourselves view the conversion to WPF and Direct2D as a move that’s being pushed forcibly by Microsoft, and as an irreversible technical step forward. But those who get all hot and bothered by new technology should think back to previous introductions, which we'll recap in this piece. Windows XP included, there is more than enough legacy technology hanging around that you can really only face the future if you’re willing to ignore the past. But alas, this disregards the realities in which most users operate, such as the well-known phobia for Windows XP shown by 780G and 785G on-board graphics chips.

We want to revisit our benchmarks from Part 1 here, but this time we’ll use our own custom-built software (readers can also download this tool from our site, and run it on their own PCs). We'll observe that even the most expensive graphics cards fall flat on some of these tests, if they’re affected by drivers that haven't been optimized for what many folks consider an older technology.