2D drawing API in Windows

Original article: 2D Drawing APIs in Windows

Background: Windows graphic programming

In Windows 7, Microsoft has made great efforts to build a new 2D drawing API. We call it Direct2D and belong to the DirectX family. The development of this API fills in some defects of the Windows graphics platform. One of the most important points is that normal 2D rendering no longer lacks hardware acceleration. In Windows Vista, we know that GDI cannot accelerate hardware. Microsoft hopes that the developed API has many modern features. For example, it supports 2D rendering of anti-aliasing and Alpha Blend, interaction with other modern graphics APIs, server-side rendering, and so on.

To help understand why Microsoft developed Direct2D, let's review the history of Windows development. The original rendering system is called GDI (graphical device interface), which still exists today. It was initially written for 16-bit Windows and then upgraded to 32-bit Windows (Windows 95 and Windows NT ). Because GDI was developed for computers with low computing power a long time ago, it does not have features such as anti-aliasing, and most APIs do not support Alpha channels.

During Windows 95, DirectX released the first version. DirectDraw is one of the earliest components. It was originally intended that, when hardware acceleration was enabled, developers could bypass WinG's permission to directly access the hardware. Such a protocol stack can be in the same status as the GDI protocol stack.

With the evolution of graphics hardware (graphics card), GDI achieves hardware acceleration through DDI (Device Driver Interface. Many video cards implement these DDI, and it is common to purchase a video card to improve your Windows performance. Next, Direct3D enters DirectX 2. Of course, it also creates its own DDI set. As a result, the video card began to invest more and more energy to make 3D graphics faster and faster, in order to maintain the huge demand of the game market. Finally, two different areas emerged: hardware acceleration and Graphic programming. The former is built around Direct3D, and the latter is centered around GDI.

Direct3D and GDI are built on different targets. The fact that they are in different locations means they cannot work together as well as expected. Although many help bridging features such as GetDC are implemented, there are always some problems in many cross-rendering scenarios. However, Microsoft did not remove these needs to be addressed.

At the turn of the century, the limitations of GDI have become increasingly apparent. Microsoft has developed a GDI extension to address these functional defects, that is, GDI +. These extensions provide support for different pixel depth formats and Alpha Blend in Primitive rendering, such as bitmap operations, paint brushes, anti-aliasing, and increasingly complex ones. In addition, GDI + supports image operations such as opening Png and Jpg files. However, all newly added operations of GDI + are not supported by hardware acceleration.

GDI + is very popular in the hosting world, mainly because it is the main force of the System. Windows. Drawing namespace. Every user-defined rendering of a very beautiful Windows Form program uses GDI + for this purpose. However, the GDI + built on GDI also inherits all the issues of interaction with Direct3D. In fact, it gets worse in some scenarios because it is always soft-rendered.

When it comes to planning to develop Windows 7, it is obvious that Microsoft needs to solve a lot of lack of interoperability and unbalanced hardware acceleration capabilities. It is quite difficult to retain existing APIs and achieve the above purpose. GDI has a long history, which needs to cope with compatibility issues of massive applications. If we want to integrate Alpha Blend support (for example) into the core API set of GDI, and do not offend existing customers, it is no different from the rest of the night. Because GDI + is built on GDI, the old bad habits make it hard to achieve hardware acceleration.

The solution is to create new APIs to include the features we want and handle interoperability problems. MIL Code (the native component for processing rendering by WPF) is a very convenient start point. It has the rendering features we want and provides both software rendering and hardware acceleration.

The first thing to do is to make the rendering code based on D3D 10.1 instead of D3D 9. The reason for this decision is that some other technologies built on this runtime version use D3D 10.1 as the basis (10Level9, WARP, D3D Primitive Remoting ). We can also see that the future hardware is also built on this architecture. This allows us to design D3D 10.1 interoperability. Therefore, you can allow interaction with other technologies, such as Direct2D.

Another interoperability task is to use the window manager and DXGI to ensure that Direct2D and GDI can work together. You can use Direct2D to draw a graph to the GDI target. Likewise, the opposite is acceptable. However, from the performance perspective, these features are not free. It just allows applications built on these two hybrid APIs to smoothly transition to the new world.

An important part of the previous work is to try to make this API expressive in terms of performance. For developers, the advantage of WPF is that it manages very important resources, but it makes it difficult to directly control hardware. This sounds simple, but there are a lot of design decisions behind it to ensure that the GPU memory is not allocated to people who don't need it and can still allow people to construct what they think. Therefore, the Direct2D design and resource/thread model that follow this principle can allow server rendering for proper scaling. But it cannot.

In addition, DirectWrite and WIC can be used for processing text and images respectively. This indicates that the Microsoft DirectX family is more componentized. Direct2D provides hardware acceleration support for DirectWrite text and WIC bitmap operations in a complementary manner.

Finally, we have built a 2D rendering API (with soft rendering) that supports hardware acceleration ). It has a collection of modern rendering primitives and can interact with previous APIs. We believe that it can completely replace the GDI/GDI + API used in most application development scenarios, and can also be used as a supplement to D3D 10.1 in some game development scenarios. A set of componentized technologies built by Microsoft completely allows developers to mix and construct previously difficult things. For example, you can render the positioned text pixels directly to the Direct3D texture without the support of any fonts.