2D performance in reverse? A Comprehensive Analysis | Retro Part 2 of 2

1 - Einführung: Die Relevanz der 2D-Grafikausgabe über das GDI 2 - Das 2D-GDI und dessen Grafikausgabe von XP bis Windows 7 im Detail 3 - 2D-Grafikausgabe über das GDI: direkt oder gepuffert? 4 - Die Symptome der HD 5xxx-Serie und deren Relevanz unter Windows 7 5 - Tom2D: Unser einfacher 2D-GDI-Benchmark 6 - Tom2D: Textausgabe 7 - Tom2D: Linien 8 - Tom2D: Kurven 9 - Tom2D: Polygone 10 - Tom2D: Rechtecke 11 - Tom2D: Ellipsen 12 - Tom2D: Blitting 13 - Tom2D: Stretching 14 - Fazit

Regardless of how Windows XP, Windows Vista, or Windows 7 handles the GDI, the methodology for programming is actually always the same to begin with. The differences in how this content is processed by the graphics card have already been explained in the previous chapter. But now you will learn how the contents are first created.

Drawing 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 just 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 has no 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 processes, the intended target is reached. Now let’s look at the differences. The elephant method is faster, more efficient, and generates less traffic. Coordinating a million ants is much more time-consuming than moving 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 don’t need any other heavy equipment (container = buffer) and that it can even be more efficient and flexible in individual cases, when you only need a few grains of sand. 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 only optimal in certain cases, because every single object is also drawn individually on the output area, which costs time.

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

We can see that as soon as a more complex drawing is to be output, the method using the buffer is much faster. The disadvantage of first needing 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 idle to rewrite the entire buffer for every small change. Let’s now examine a case in which direct output is a natural choice.

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 make no sense to redraw everything for each of the intermediate positions at which the mouse is currently located, to fill the buffer and then to output it. Here one uses a trick. With the help of the ROP (Raster Operator) one can proceed with XOR (exclusive OR) as follows.

If you overlay two identical objects with XOR, they cancel each other out. Moving an object by drawing it 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 location. This makes this object “disappear” 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 with 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-steady, direct drawing on a device is also called “floating drawing”. We will keep this process in mind, because we will have to go into it again in the next section, when we talk about the symptoms in the 2D behavior of the HD5xxx.

Another task is the representation of so-called “floating objects”. By this we mean, 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 become quite 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 whether we use our own 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 a bit slower than under WDDM 1.0 and struggles with the same causes as under Vista. The additional hardware acceleration for GDI content that is available again is unfortunately very limited. We’ll have to take all this into account when we talk about the benchmark later on and want to evaluate the results properly.