2D power in reverse? A comprehensive analysis! | Retro 10 years ago

1 - Introduction and the role of the 2D output via GDI 2 - The 2D GDI and the graphic output from XP to Windows 7 3 - 2D GDI: direct or buffered output? 4 - The symptoms of the HD 5xxx series and the follows in Windows 7

Regardless of how Windows XP, Windows Vista or Windows 7 handles the GDI, the programming methodology is always the same. The differences in how these contents are processed by the graphics card have already been explained in the previous chapter. How the content is first created, however, that you will now learn.

Character commands

No matter what we would like to output via the GDI in 2D, everything is based on a fixed structure of standardized drawing commands. In detail it would surely go beyond the scope of this article, so only this much: no matter whether lines, curves, polygons, rectangles, ellipses or whatever geometric shape and its properties (filling, line thickness and color, etc.) – there is a precisely defined command for each of these tasks. This is passed to the GDI by the current application program together with the necessary parameters.  The respective application then no longer has any influence on the rest.

Direct and buffered drawing: the ant-elephant comparison

In principle, it doesn’t matter whether a million ants each carry a grain of sand 100 m from A to B, or whether the ants carry these grains of sand into a collection container 50 cm away, which is then pulled to its destination by a single elephant. In both operations, the intended objective is achieved.  Now let’s look at the differences. The elephant method is faster and more efficient and less traffic is generated. Coordinating a million ants is much more time-consuming than transporting a container once and then dumping it all at once at the destination. It also takes considerably more time. The advantage of the ant method is that you do not need any further heavy aids (container = buffer) and that in individual cases, if you only need a few grains of sand, it can even be more efficient and flexible. So it always depends on the task and the quantity. Therefore, let us now consider drawing via the GDI to an output device (monitor) in analogy to these examples.

Direct drawing according to the ant method Slow and optimal only in certain cases, because each individual object is also drawn individually on the output area, which takes time.

Indirect drawing according to the elephant method: A buffer first collects all contents invisibly, the visible outputis done at the end for all objects together and only once.

We see that as soon as a more complex drawing is to be output, the method using the buffer is much faster. The disadvantage that you first need a so-called device-independent bitmap (DIB) for buffering, which has the same size as the visible output area (e.g. full screen or drawing area of a CAD program), is quickly compensated by the speed advantage. On the other hand, it would be useless to rewrite the entire buffer for every small change. Let us now examine a case in which a direct output just lends itself.

Real-time output when creating and editing drawing objects

If, for example, you want to move a geometric object (e.g. a polygon) from position A to position B on the drawing area in real time using the mouse in a drawing program, then it would be pointless to redraw everything for each of the intermediate positions where the mouse is currently located, fill the buffer and then output it. Here one makes use of a trick. Using the ROP (Raster Operator), you can XOR (exclusive OR) as follows.

If two identical objects are superimposed with XOR, they cancel each other out. Moving an object by drawing directly on the output area using the raster operator (XOR) is also one of those things:

You first draw the object to be moved again directly on the output device using XOR at the old position. As a result, this object “disappears” on the output surface as if by magic. Now draw the object directly and without XOR to the new position, so that it becomes visible there again. This is repeated for every single mouse movement, so that 10-50 position changes can be displayed within one second. The lazy eye perceives this as a smooth and flowing process without flickering. Only at the end is the buffer completely refilled and output. This method of non-stationary, direct drawing on a device is also called “floating drawing”. We’ll keep this in mind, because we’ll need to revisit it in the next section when we talk about the symptoms in the HD5xxx’s 2D behavior.

Another field of activity is the representation of so-called “floating objects”. This includes, for example, all marker points which, depending on the selected processing mode, serve as drawing and orientation aids and whose display, if there are a large number of them, can also be problematic. These objects are not a fixed part of the drawing and are not buffered by almost any program.

Inferences:

If we consider what we have just read with the individual flowcharts in the previous chapter, we find that 2D GDI output under XP can be hardware-accelerated and without detours. Under Vista, it almost doesn’t matter if we use a custom buffer or send each command directly to the output device – the entire window is buffered again anyway. Under Windows 7 with WDDM 1.1 drivers the second buffer is omitted and only the changes are shown.  The direct sign is slightly slower than under WDDM 1.0 and struggles with the same causes as under Vista. The additionally available hardware acceleration for GDI content is unfortunately very limited. We have to take all this into account if we want to talk about the benchmark later on and evaluate the results properly.