Windows 2000 Graphics API Black Book with Cdrom
Authors: Damon Chandler, Michael Fotsch
Venue:  (2001)

From the Book: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. 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 all that 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 follows 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 applications, the GDI is used, to some extent, by every Windows application. Despite its prevalence, the GDI is one of 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, often 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 between the types' compression schemes, and we'll discuss how you can read and write JPG and PNG files. The companion CD-ROM contains numerous 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 often 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 developing 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-we 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 has been 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. How to Use This Book Most of the chapters of this text are independent. You don't need to read the book in a serial fashion. And, when applicable, we'll refer you to the related chapters. To understand the code, however, you will need at least a basic understanding of general Windows programming, pointers, C++ references, and exception handling. In most cases, whatever language you use, if you're familiar with general programming, it's not too difficult to translate. A Note on Common Windows Entities Although we provide an explanation for most of the graphics-API-related types, structures, and macros, you should be familiar with those that are common to general Windows development. Some of the more ubiquitous ones are: HANDLE, HGLOBAL, HINSTANCE, HWND, MSG, LPARAM, WPARAM, BYTE, WORD, DWORD, POINT, RECT, SIZE, COLORREF, RGB, and PALETTERGB. A Note on Exception Handling Because we want to endorse good programming practices (and thus reliable code), we've strived to use exception handling wherever it's needed (and in some cases, even when it's not). We've also tried to avoid using specific exception classes that might be ambiguous to non-C++ developers (and even some C++ compilers). To this end, whenever you see code like the following: memory_buffer = some_memory_allocation_function(); try { if (some_function() == SOME_ERROR_CONDITION) { throw; // or, throw "some error message"; } } catch (...) { // error-handling/clean-up code... some_memory_deallocation_function(memory_buffer); some_error_reporting_function(); } some_memory_deallocation_function(memory_buffer); you should replace the generic throw statement with one that's more applicable to your code, and you should replace the generic catch statement with one that's designed to handle the type of exception that you raised. For example, if you were using the Standard C++ Library's runtime_error class, you'd do the following: memory_buffer = some_memory_allocation_function(); try { if (!some_function()) { throw std::runtime_error("argh!"); } } catch (std::runtime_error& e) { // error-handling/clean-up code... some_memory_deallocation_function(memory_buffer); MessageBox( GetForegroundWindow(), TEXT(e.what()), TEXT("Runtime Error!"), MB_OK | MB_ICONERROR ); } some_memory_deallocation_function(memory_buffer); Also, if you haven't done so already, familiarize yourself with the documentation that accompanies your specific development environment and compiler. In particular, know how to include the required header files and how to link with static and dynamic libraries. (If you're having problems with these issues, feel free to contact us via email; our email addresses are provided at the end of this introduction.) The Black Book Philosophy Written by experienced professionals, Coriolis Black Books provide immediate solutions to global programming and administrative challenges, helping you complete specific tasks, especially critical ones that are not well documented in other books. The Black Book's unique two-part chapter format-thorough technical overviews followed by practical immediate solutions-is structured to help you use your knowledge, solve problems, and quickly master complex technical issues to become an expert. By breaking down complex topics into easily manageable components, this format helps you quickly find what you're looking for, with the diagrams and code you need to make it happen. We welcome your feedback on this book. You can either email The Coriolis Group at ctp@coriolis.com or email us directly at dmc27@ee.cornell.edu and foetsch@crosswinds.net. Errata, updates, and more are available at www.coriolis.com.