Introduction

Application development is one of the most rewarding, yet, frustrating fields to work in. It really is amazing how one profession can send you on such an emotional roller-coaster ride. One minute you're pulling your hair out, cursing the engineers at Microsoft. The next minute you're ready to pop open a bottle of champagne. Most of the time, however, you're staring at the progress of the compiler, waiting in anticipation as if the results will make or break you. And, when you do finally get things working, you realize that either you learned a great deal in the process, or you'll never again trust Microsoft's documentation.

Admit it—how many times have you read a cryptic explanation of a function or a technique and wasted so many hours simply because someone neglected to mention a common pitfall? It's completely frustrating! Unfortunately, it seems as if too many things are explained in hieroglyphics—all too often without code examples. (In many cases, I personally find examples more explanatory than the text itself.) Think about it for a moment. The ultimate goal of documentation is to exchange information; and, if you can't get this information across, what's the point? Would the TV Food Network be so popular if Emeril just sat in front of the camera reading from a cookbook? No, of course not! On the other hand, if Emeril is cooking, but you have your TV muted, you're still not going to know exactly what to do. Whatever the task at hand is—whether you're preparing a gourmet meal, solving a difficult equation, or, in our case, developing applications—the point is, your source of information must contain a good mix of background information and hands-on examples.

Nowadays—with the increasing availability of high-end processing power and the rapid decrease in the cost of video-display components—more and more applications are including graphics-based content. This trend places a great demand on the contemporary developer, and makes a basic understanding of graphics programming a vital part of any curriculum. Though, perhaps more than any other programming interface, the Windows graphics API doesn't leave room for error; many of the techniques require a strict procedure that must be followed to the letter. Often, this scheme forces you to memorize a specific set of function calls that are easily forgotten.

We've written Windows 2000 Graphics API Black Book with two primary goals in mind: First, as a definitive problem-solver, this text is designed to alleviate the chore of rote memorization. As you'll soon discover, many graphics-based techniques aren't at all difficult—there's certainly no rocket science or magic to it. The fact remains, however, that if you've forgotten which functions to call, or if you've never before attempted the solution, there's a good chance that you'll waste several hours just trying to get this—conceptually simple—technique to work. Well, we've learned (from personal experience) that this is an all too common situation. As a result, each chapter of this text contains an "Immediate Solutions" section that provides systematic answers, or "recipes," that you can follow to get the task accomplished quickly. When you're in a bind, who cares about a lengthy explanation—you simply follow the recipe, learn from the example, cut and paste the code from the CD-ROM, and then move on to the next task. (Don't get us wrong, we're not trying to endorse bad habits, but we've all done our fair share of cutting and pasting.) Second, and perhaps more importantly, this text aims to answer the whys. "Why do I use function X instead of function Y? Why is this technique faster than the others? Why is this function named so and so?" To answer these questions, each chapter opens with a thorough "In Depth" section that provides the theory behind the solutions. In this way, Windows 2000 Graphics API Black Book serves as both a reference and an explanatory guide.

Is This Book for You?

Windows 2000 Graphics API Black Book was written with the intermediate or advanced user in mind. This book's topics include:

• The Windows Graphics Device Interface (GDI)—The GDI is the foundation of the Windows user-interface. Use of the GDI can be seen throughout Windows—from simple controls such as the Start button, to complex images such as the thumbnail previews in Explorer. Designed primarily for business- and desktop-publishing-type applications, the GDI is used, to some extent, by every Windows application. Despite its prevalence, the GDI is one the most difficult Windows-based technologies to work with; it presents many pitfalls that oftentimes leave developers scratching their heads. For this reason, Chapters 1 through 10 provide a comprehensive treatment of the Windows GDI, presenting effective solutions to the most commonly encountered problems.
• DirectDraw—DirectDraw is a component of the DirectX library that allows applications to take advantage of enhanced video hardware capabilities. Many display adapters, for example, possess specific integrated circuits designed to handle the task of rendering textures. Using DirectDraw, an application can access such capabilities for enhanced performance. When specific hardware is absent, DirectDraw emulates the functionality through its HEL (Hardware Emulation Layer). Though DirectDraw is designed primarily for games, it can be used in any application and even in conjunction with the GDI. In Chapters 11 through 15, we provide a task-oriented treatment of DirectDraw, oftentimes drawing parallels to corresponding GDI-based approaches.
• Image Color Management (ICM) 2—Microsoft's Image Color Management technology gives applications the ability to control the way an image will appear on a specific device. For example, the ICM services can be used to ensure that the printed version of a Web page will appear as close as possible to what appears on the screen. Such functionality is most often required when the range of printable colors is only a subset of the range capable of being displayed by the monitor, as is the case for most printers. This argument holds true for image acquisition devices as well. In Chapter 16, we'll take an in-depth look at the motivation behind image color management, and we'll examine how you easily incorporate ICM 2 technology into your applications.
• Image processing—Manipulating the pixels of an image to achieve a special effect is easier said than done. Sure, it's simple enough to manipulate the color of each pixel, but what if you want to alter an image's frequency components. What if you want to change the shape of only a particular object within an image? Or what if you want to morph two images? In Chapter 17, we address these questions and a whole lot more. We'll discuss intensity-based manipulations, geometrically based manipulations, and frequency-based manipulations. We'll also discuss a bit of signal processing theory, and we'll demonstrate how to compute the discrete cosine transform and the discrete wavelet transform.
• Image file formats—Although the Windows API provides native support for bitmaps, most applications aren't limited to only this format. In Chapter 18, we examine two of the most common types of compressed images: JPEGs and PNGs. We'll discuss the differences behind the types' compression schemes, and we'll discuss how you can read and write JPG and PNG files.

The companion CD-ROM contains a numerous set of code examples, demo applications, utility functions, and useful C++ classes that reinforce the concepts from the text. We've included projects for both Microsoft Visual C++ and Borland C++Builder.

An Overview of Windows Graphics

Back in the command-line era, there was little need for any type of standard graphics interface. Most applications were completely text-based, and the idea of painting a control to the screen oftentimes seemed unnecessary or beyond the scope of an application. Those applications that did require a graphics-based display employed the use of a proprietary graphics interface. In the early 1990s, the release of Windows 3 necessitated the inclusion of a standard graphics interface. The idea was to provide a common means by which an application could render its controls so as to conform to the rest of the graphics environment. The Windows Graphics Device Interface, or GDI for short, filled this role and, at the same time, reduced most third-party interfaces to obsolescence. You can probably imagine the chaos that might result when separate interfaces attempt to simultaneously access the display device driver. Eliminating the developer's role of delegating these interfaces was a primary motivation for the GDI.

Conceptually, the GDI is nothing more than an abstract layer between the developer of a Windows-based application and a device driver. This statement lacks a device specification because the GDI can be used to render graphical representations to a whole slew of different devices. For example, you can use the GDI to produce graphical output on a plotter or printer, as well as on the display monitor. In fact, you rarely have to worry about the specifics of how the interface communicates with separate devices. Instead, you can think of the GDI as a common set of structures and functions that can be used for drawing and painting. There are, of course, some limitations to this rule; rarely is Microsoft technology so straightforward. Don't worry though—I'll give you a heads up when things get nasty. And if the Windows GDI just isn't your cup of tea, you can quickly refer to a DirectDraw-based solution.

DirectDraw was introduced in 1995 as part of the DirectX set of APIs. This set of APIs was developed to facilitate the creation of games and multimedia applications for the Microsoft Windows operating system. With the help of DirectX, Windows 95 soon replaced MS-DOS as the premier platform for PC games. However, you'll notice that DirectX is useful not only for games but for other applications as well.

DirectDraw, as the 2D graphics component of DirectX, gives applications low-level access to the display hardware. With DirectDraw, it's possible to use special hardware features that are not exposed through the Windows GDI. DirectDraw was also designed to be compatible with the widest possible variety of display devices. DirectDraw is even capable of emulating features when the hardware does not support them directly.

In the past few years, DirectDraw was under constant development. With version 7 of the DirectX runtime (DirectX 7 is an integral part of the Windows 2000 operating system), the DirectDraw API is finally complete. DirectX 8, which was released in November 2000, continues to support DirectDraw. This book is the complete guide to high-performance 2D graphics in Windows 2000 and future operating systems. We'll cover everything from DirectDraw initialization to setting up full-screen applications, taking advantage of hardware-acceleration, gaining direct access to the video memory, using stereo vision, and much more.

Used by permission of The Coriolis Group, LLC.

< Previous Next >