2D Graphics Output Using GDI: Direct Or Buffered?
It doesn’t matter how XP, Vista, or Windows 7 interact with GDI; from a programming standpoint, coding methods all remain the same. How those implementations differ is what we covered in the preceding section of this story, particularly when it comes to the graphic card. How this actually work for these OSes is what we cover here in this section.
Line-drawing Commands
No matter what we might want to say about 2D output from GDI, everything is based on a well-established collection of standardized drawing instructions. Because the details of those instructions fall outside the scope of this story, we have only this much to say about it here: each of the graphics primitives, including lines, curves, polygons, rectangles, and ellipses, has its own well-defined command, including properties like area fills, line width, color, and so forth. We’ll describe these commands along with any associated parameters they might take, just as they’re passed to the GDI. Anything that happens after that falls outside the active application’s control anyway.
Direct and Buffered Drawing: Comparing Ants to Elephants
In principle, it shouldn't make a difference if a million ants carry grains of sand 100 feet from point A to point B, or if you load a big container full of sand onto the back of an elephant and move all that sand in a single transfer. Both approaches achieve the same goal.
Nevertheless, let’s examine the differences between these approaches: the elephant involves a lot less traffic between the two endpoints. Coordinating the efforts of a million ants takes more time and effort than loading and hoisting a single container onto the elephant.
The benefit of the ant method is that no additional container (or buffer) is needed to convey the materials. Also, when only a few grains of sand need to be moved, ants are more efficient and flexible than elephant. It always comes down to the types of activities and the amount of data under consideration as to which side wins. Now, let’s look at how drawing proceeds using GDI to paint a display device (monitor).
It’s easy to see that as soon as more complex drawing commands must be rendered, the buffer method works noticeably faster. The disadvantage inherent to this method is that a form of temporary storage (called a device-independent bitmap [DIB]) that’s equal in size to the visible display region is required.
Fortunately, the resource cost is usually more than offset by the increase in rendering speed that this approach affords. Of course, this also means that when only small changes are needed, the entire buffer must still be populated and then copied to the graphics card or window manager. Let’s look at one particular case when a direct output is enabled.
Real-time Output when Positioning and Editing 2D Objects
For example, if you want to use the mouse to move a geometric shape, such as a polygon, from position A to position B on the drawing surface, it wouldn't make sense to re-draw that object for each point along the cursor path between those two points, where each such rendering requires filling the buffer then rendering its contents. With the help of the ROP (raster operator), it’s much more straightforward to proceed using XOR (exclusive OR) rendering techniques.
First, you must redraw the object using XOR at its prior location directly on the display device. This causes the original object to “disappear” on the display surface, as if by magic. Next, you must draw that object in the new position sans XOR to make it appear in its new location. Repeat this process for each individual mouse movement, and it’s possible to render anywhere from 10-50 position changes every second. The human eye sees this kind of movement as smooth and flicker-free. Only when the final position is reached will the buffer be completely refilled and then redrawn on-screen.
This method aside, direct drawing to the display device is called “floating drawing.” Please take note of this process, because we will refer back to it in our next section, when it comes to explaining the 2D behavior of the ATI Radeon HD 5000-series graphics cards as they sit today.
Another point of discussion comes from the rendering of so-called “floating objects.” This subject includes all of the marking points used to guide how drawings are displayed and oriented when they’re rendered on-screen, along with the graphics primitives involved. As the number of such objects or values gets progressively larger, graphics problems may manifest themselves. They are not a constant element for drawing on-screen, and aren’t buffered in the vast majority of programs.
Conclusions
Looking back at the various diagrams in the preceding section we can see that 2D hardware acceleration is supported in Windows XP and involves no detours for direct graphics output. In Vista, it really doesn’t matter if we use a buffer or attempt to send each drawing instruction directly to the display device. The whole window gets buffered along the output path anyway. For Windows 7 with WDDM 1.1 drivers, we lose the second buffer so that only changes need be updated on-screen.
