The Limits Of 2D: One Space With Many Windows
Rendering and 2D Acceleration in Windows
If you look a
t 2D rendering inside any display window, only two dimensions apply: X and Y, or width and height. What’s missing? Any kind of depth information.
In Windows, 2D graphics get rendered thanks to the GDI (Graphics Device Interface). This interface supports all of the higher-level programming languages, and includes all of the important graphics functions necessary to render 2D graphical objects. Later enhancements, such as GDI+ and Direct2D, don’t play much of a role here because GDI is (and remains) the most important tool for 2D graphical output in applications. The critical drawing functions for pixels, lines, curves, polygons, rectangles, ellipses, and so forth were initially all calculated on the CPU. Thanks to focused specialization in graphics cards, later generations of hardware delivered faster 2D calculations and rendering. This early form of 2D acceleration remains important even today, but no longer takes two-dimensional acceleration as its primary focus. To make the most of graphics performance, we need a third coordinate.
Simple Rendering of Multiple Windows without Hardware Acceleration
The original 2D rendering method that lurks behind overlapping display windows is both simple and straightforward. One needs to know two things: first, the area on screen inside any window that has changed (and thus, must be redrawn), and second, the order in which windows or objects overlay one another (whether it’s visible in whole or in part, or covered by some other window). This type of information offers two-and-a-half dimensions, or layered graphics, where a third coordinate takes a 0 (hidden) or 1 (visible) value as a kind of "helper dimension." That’s why you’ll hear Windows experts talk about 2.5D graphics.
After order or visibility issues are decided, visible window contents may be drawn using purely two-dimensional graphics functions. Nevertheless, it’s not only necessary to render display window contents completely, but it’s also necessary to manage numerous types of information and window content displays. What happens, for example, when windows get moved? Whenever another window contains a region that is partially or completely revealed as a consequence, the system graphics routine WM_PAINT must be called with precise information to indicate which rectangular region must be redrawn ("dirty rectangle"). Optimized implementations will reconstruct or redraw this area. Sadly, many implementations instead opt to redraw the whole window, despite ready access to more precise instructions, whether or not it needs to be completely or only partially reproduced. This can have a profound effect on graphics performance. Another disadvantage is the well-known and despised blurring or repeat effect that often occurs when windows get dragged quickly across the screen on a system that lacks hardware acceleration.
Let’s sum up what we’ve reviewed so far. There are individual windows on display, whose two-dimensional contents must be drawn on-screen so they may be viewed. These windows can be moved arbitrarily, so that they can overlap and be partially or completely obscured by other windows. The visible contents from all of these windows need to managed, and to be drawn on-screen with an absolute minimum delay. We also know that the CPU itself, even for very fast processors, can be overwhelmed in performing such complex tasks. What else is there to do, except to offload this onto the graphics card? What this entails, and how it sounds simpler in concept than in actual practice, is what we tackle in the next section.
