DirectX Developer Blog

Introducing the DirectCompute Lecture Series!

2010-06-16T01:17:00Z

We are very excited to announce the DirectCompute Lecture Series, which starts today, June 14th, and runs for the next three weeks. A component of DirectX, DirectCompute is Microsoft’s GPGPU programming solution that enables developers to utilize the GPU for general purpose computing on Windows. In today’s opening video lecture, Robert Hess hosts a round table discussion of thought leaders in parallel computing. Six lectures will follow about DirectCompute, developing DirectCompute applications, and tips for optimizing performance and integrating the DirectCompute data into the graphics pipeline.

Each week we will release two new lectures, Mondays and Fridays, that are presented by developers experienced with parallel computing and DirectCompute. Several lectures will address key parallel programing scenarios. The series will begin with high-level topics common to most DirectCompute scenarios, and continue into deeper lectures that examine more complex problems and algorithms.

With the realization that GPUs are useful for purposes other than graphics, the need for APIs to harness their potential has grown rapidly over the last several years. Microsoft developed DirectCompute in response to this need. Its benefits for mass-market applications are numerous. Because it can run on all DirectX 11 hardware and most DirectX 10.1 hardware, you can safely use DirectCompute for core application functionality across many customer segments. Additionally, as part of the Direct3D API, DirectCompute can be seamlessly integrated with games, CAD tools, and other graphics applications.

The integration with Direct3D makes DirectCompute an attractive choice for any scientific computing applications that require data visualization. The Compute Shader Extensions library provides access to high-performance implementations of common computing algorithms, such as parallel prefix reduction and multi-dimensional fast Fourier transform.

If you are interested in doing some GPU computing, look for our video lectures at http://go.microsoft.com/fwlink/?LinkId=194362, which will point to the lectures as they become available.

Currently, the following lectures are planned:

Direct Compute Expert Roundtable
Lecture Course Level - 100
Recommended Prerequisite: N/A
Mediator: Robert Hess (Director, Platform Evangelism, Microsoft Corporation)
Participants:
- Eric Young (Manager of Developer Technology, NVIDIA Corporation)
- Chas Boyd (Program Manager Architect Windows Graphics, Microsoft Corporation)
- Justin Hensley (Senior MTS, AMD Office of CTO, ATI/AMD)
Lecture Length: 45 Minutes
Web Release Date: Monday 6/14/2010

Introduction to DirectCompute

Lecture Course Level: 101
Recommended Prerequisite: None
Presenter: Chas Boyd (Program Manager Architect Windows Graphics, Microsoft Corporation)
Lecture Length: 25 minutes
Web Release Date: Friday 6/18/2010

DirectCompute Memory Patterns

Presenter: Matt Sandy (Program Manager Microsoft Graphics, Microsoft Corporation)
Lecture Course Level: 110
Recommended Prerequisite: Introduction to DirectCompute
Lecture Length: 15 Minutes
Web Release Date: Monday 6/21/2010

Basics of DirectCompute Application Development

Presenter: Jason Yang (MTS Software Engineer, ATI/AMD)
Lecture Course Level: 120
Recommended Prerequisite: Introduction to DirectCompute
Lecture Length: 30 minutes
Web Release Date: Friday 6/25/2010

DirectCompute GPU Optimizations and Performance

Presenter: James Fung (Developer Technology, NVIDIA Corporation)
Lecture Corse Level: 210
Recommended Prerequisite: DirectCompute Memory Patterns
Lecture Length: 22 minutes
Web Release Date: Monday 6/28/2010

DirectCompute GPU Accelerated Physics

Presenter: Lee Howes (Sr. Software Development Engineer, ATI/AMD)
Lecture Course Level: 230
Recommended Prerequisite: DirectCompute Memory Patterns and Basics of DirectCompute Application Development
Lecture Length: 30 minutes
Web Release Date: Friday 7/1/2010

DirectCompute - Integration with the Graphics Pipeline

Presenter: James Fung (Developer Technology, NVIDIA Corporation)
Lecture Course Level: 250
Recommended Prerequisite:
Lecture Length: 18 minutes
Web Release Date: Monday 7/5/2010

New DirectX Whitepapers and Samples Published for Windows 7 and Windows Vista

2010-01-06T21:17:00Z

Surface Sharing Support for Windows Graphics Applications Whitepaper and Samples

A whitepaper and two samples were published to showcase interoperability support using surface sharing between Windows graphics APIs: Direct3D 11, Direct2D, Direct3D 10, and Direct3D 9Ex. The interoperability support explained applies to both Windows 7 and Windows Client Platform Update for Windows Vista.

Both the whitepaper and sample applications help developers use multiple APIs to render to the same surface in an application designed for Windows 7 or Windows Vista operating systems.

- Best practice guidelines and pointers to additional resources are available in this whitepaper http://msdn.microsoft.com/en-us/library/ee913554(VS.85).aspx

- Sample application for synchronized shared surface support is available on http://code.msdn.microsoft.com/DXGISyncSharedSurf

- Sample application using the shared surface queue helper utility is available on http://code.msdn.microsoft.com/D3D9ExDXGISharedSurf

Windows 7 Direct3D9Ex Presentation Improvements for Video Applications Whitepaper and Sample

Flip Mode Present and its associated Present Statistics in Direct3D 9Ex and Desktop Window Manager were added in Windows 7 to allow applications to reduce the system resource load when DWM is enabled. Present Statistics enhancements associated with Flip Mode Present enable Direct3D 9Ex applications to better control the rate of presentation by providing real-time feedback and correction mechanisms.

- Detailed explanations and pointers to sample resources are included in this whitepaper http://msdn.microsoft.com/en-us/library/ee890072(VS.85).aspx

- Sample application using Direct3D9Ex Flip Mode Present and its Present Statisics is available on http://code.msdn.microsoft.com/D3D9ExFlipEx/

Direct2D and DirectWrite

2009-12-18T02:04:00Z

One of the more interesting aspects of Direct2D is that it cooperates with another API, DirectWrite in order to handle text. This is unlike other monolithic APIs, such as GDI, GDI+ or WPF. This post explores why these components are separated in this way, as well as differences and similarities between them.

Incremental Adoption

One of the lessons learned by the DirectX team is that many applications cannot move completely over to a new graphics API in one release. This might be because they need to support plug-ins that still take the older interfaces, because the application itself is too large to port over to a new API in one release or because some part of the newer API is really desirable but the older API is working well enough for other parts of the application. Providing a separate component dedicated to text allows a component to adopt DirectWrite while still leaving their application GDI or GDI+ based. Having two distinct but highly interoperable APIs allows customers to only pay for the IO and working set of the APIs they use in their application.

Text Services versus Rendering

As applications have evolved, their text processing requirements have grown increasingly complex. Initially, text was generally confined to statically laid-out UI, and the text was rendered within a well-defined box, such as a button. As applications had to be shipped in more languages this approach became more difficult to sustain since both the width and height of the translated text can vary substantially between different languages. To adapt, applications started having to dynamically lay out their UI depending on the actual rendered size of the text, rather than the other way around.

To help applications with this task, DirectWrite provides the IDWriteTextLayout interface. This API allows an application to specify a piece of text with complex characteristics such as: different fonts and font sizes, underlines, strikethroughs, bi-directional text, effects, ellipsis and even embedded non-glyph characters (such as a bitmap emoticon or an icon). The application can then change various characteristics of the text as it iteratively determines its UI layout. The layout can either position the glyphs ideally based on their widths (as WPF does), or, it can snap the glyphs to the nearest pixel positions (as GDI does). As well as obtaining text measurements, the application can hit test various parts of the text. For example, it might wish to know that a hyperlink in the text has been clicked on.

The text layout interface is completely decoupled from the input technology and the rendering API the application chooses to use. As shown below:

This separation is accomplished by allowing an application to implement a callback interface (IDWriteTextRenderer) and then target a particular glyph rendering API to render the laid-out glyphs. For GDI, this would be ExtTextOut, for Direct2D ID2D1RenderTarget::DrawGlyphRun and for DirectWrite IDWriteBitmapRenderTarget::DrawGlyphRun. Conveniently, DrawGlyphRun in both Direct2D and DirectWrite have exactly compatible parameters to the DrawGlyphRun method that the application implements on IDWriteTextRenderer.

Following a similar separation, text specific features such as font enumeration and management, glyph analysis, etc. are handled by DirectWrite rather than Direct2D. The DirectWrite objects are accepted directly by Direct2D. To help existing GDI applications to take advantage of DirectWrite, it provides the IDWriteGDIInteropMethod interface with methods to:

· Create a DirectWrite Font from a GDI Logical Font (CreateFontFromLOGFONT).

· Convert from a DirectWrite Font Face to a GDI Logical Font (ConvertFontFacetoLOGFONT).

· Retrieve the Direct Write Font Face from the one currently selected into an HDC. (CreateFontFaceFromHDC).

· Create a DirectWrite bitmap render target in system memory (CreateBitmapRenderTarget).

Glyphs versus Text

Both Direct2D and DirectWrite have a very strict separation in the API between Text and Glyphs. Text is a set of Unicode code points (characters), with various stylistic modifiers (fonts, weights, underlines, strikethroughs etc.) that is laid out within a rectangle. A glyph, in contrast, is a particular index into a particular font file. A glyph defines a set of curves which can be rendered, but, it doesn’t have any textual meaning. There is potentially a many to many mapping between glyphs and characters. A sequence of glyphs that come from the same Font Face and that are laid-out sequentially on a baseline is called a GlyphRun. Both DirectWrite and Direct2D call their most precise glyph rendering API DrawGlyphRun and they have very similar signatures. We’ll show Direct2D’s:

STDMETHOD_(void, DrawGlyphRun)(

D2D1_POINT_2F baselineOrigin,

__in CONST DWRITE_GLYPH_RUN *glyphRun,

__in ID2D1Brush *foregroundBrush,

DWRITE_MEASURING_MODE measuringMode = DWRITE_MEASURING_MODE_NATURAL

) PURE;

Each glyph run starts at an origin and is placed on a line starting from this origin. The glyphs are modified by the current world transform and the selected text rendering settings on the associated render target. This API is generally called directly only by APIs that do their own layout (For example a Word Processor) or by an application that has implemented the IDWriteTextRenderer interface.

DirectWrite and Direct2D

Architecturally, it would be ideal for Direct2D and DirectWrite to have a clear distinction of roles. Direct2D would provide rendering services (DrawGlyphRun) and DirectWrite would provide layout, fonts and other text services. However, during the design of Direct2D, we very quickly realized that asking an application to implement the text rendering interface to replace the equivalent of USER32’s DrawText API would probably be too large a burden initially. Conversely, applications will want a way to do basic glyph rendering through DirectWrite without pulling in all of D2D. So, the relationship is a little more complex, and DirectWrite provides for glyph rendering through the IDWriteBitmapRenderTarget::DrawGlyphRun API. Similarly Direct2D provides some APIs that accept text rather than Glyphs through ID2D1RenderTarget::DrawTextLayout and ID2D1RenderTarget::DrawText. An application’s usage of text tends to start simple: put OK or Cancel on a fixed-layout button, for example. But, over time it becomes more complex as internationalization and other features are added. Eventually many applications will reach the point where using DirectWrite’s text layout objects and implementing the text renderer will become necessary.

For this reason, Direct2D provides layered APIs that allow an application to start simply and grow more sophisticated without having to back-track or abandon their working code. A simplified view is shown below:

DrawText

This is the simplest of the APIs to use. It takes a Unicode string, a foreground brush, a single format object and a destination rectangle. It will lay-out and render the entire string within the layout rectangle, and optionally clip it. This is useful when putting a simple piece of text within a piece of fixed-layout UI.

DrawTextLayout

If the application would like to start measuring and arranging the text and other UI elements, or, if it wants to support multiple fonts, styles, underlines and strikethroughs; it can create a text layout object using DirectWrite. Direct2D provides the DrawTextLayout API that directly accepts this object and renders the text at a given point. (The width and height are provided by the layout object). As well as implementing all of the expected text layout features, Direct2D will interpret any effect object as a brush and apply that brush to the selected range of glyphs. It will also call any inline objects, which allows an application to insert non-glyph “characters” (icons) into the text if it wishes. Another advantage of using a text layout object is that the glyph positions are cached in it. Hence, there is a large performance gain to be had by reusing the same layout object for multiple draw calls and avoiding recalculating the glyph positions for each call. This capability is not present for USER32’s DrawText.

DrawGlyphRun

Finally, the application can implement the IDWriteTextRenderer interface themselves and call DrawGlyphRun and FillRectangle themselves (or any other rendering API). All of the existing interaction with the Text Layout object will remain unchanged.

Glyph Rendering in Direct2D versus DirectWrite

DirectWrite allows an existing GDI application to obtain advanced text rendering features such as:

· Sub-pixel ClearType. This allows an application to place glyphs on sub-pixel positions to allow for both sharp glyph rendering as well as even glyph layout.

· Y-direction anti-aliasing. This allows smoother rendering of curves on larger glyphs.

The application can obtain these without having to pull in other DirectX APIs through the IDWriteBitmapRenderTarget API. This allows glyphs to be rendered with a solid color to a memory DC. An application moving to Direct2D will also obtain the following features:

· Hardware acceleration.

· The ability to fill text with an arbitrary brush. (Radial Gradients, Linear Gradients and Bitmaps).

· More support for layering and clipping through the PushAxisAlignedClip, PushLayer and CreateCompatibleRenderTarget APIs.

· The ability to support Grayscale text rendering. This correctly populates the destination alpha channel according to both the text brush opacity and the anti-aliasing of the text.

In order to efficiently support hardware acceleration, Direct2D uses a slightly different approximation to Gamma correction called “alpha correction”. This doesn’t require Direct2D to inspect the render target color pixel when rendering text. Although this could be done entirely on the GPU by reading from the render target to another texture, this would prevent Direct2D from batching its calls to Direct3D efficiently since a batch would not be able to span any render target read-back. (See the MSDN article by Kenny Kerr to obtain more information about Direct2D batching).

Conclusion

We hope that this article helps you understand the differences and similarities between Direct2D and DirectWrite as well as the architectural motivations for providing these as separate technologies. For more information please see:

· The Direct2D reference on MSDN

· The DirectWrite reference on MSDN

Animated 2D Graphics for UI, Games, and Demos

2009-12-12T02:14:00Z

Introduction

In this post, I present a sample animation framework that demonstrates how Direct2D and DirectWrite can be used in a wide variety of applications. This post is targeted at game developers and demoscene coders who want to take advantage of modern hardware-accelerated components.

Direct2D was designed for applications that need graphics intensive operations and yet demand high performance and reliability; these applications include internet browsers, office applications, and graphics editors. But Direct2D’s applicability extends beyond these problem domains and well into the realms of games and art.

Graphics sell games. Therefore, they need to be very fast and look great. Even though the majority of games are heavily 3D, there is also a large chunk of 2D graphics in games, particularly UI components and textures. Also games from some genres, such as puzzle, strategy, and educational games, mostly use 2D graphics.

Then there is the “demoscene,” a competitive, computer arts subculture, where teams of amateur coders, musicians and graphics artists create demos, programs that include hard-to-code visual effects with graphics and synchronized music, much like music videos. 2D graphics in particular is a rising trend in demos in the last few years (see Masagin by Farbraush & Neuro or Metamorphosis by ASD for example)

While differences remain among a graphical editor application such as Adobe Illustrator, a real time strategy game and a demoscene demo, they present some of the same challenges:

A continuous float 2D problem space: The focus can move to different sections of the space, zooming in and out.
Lots of cool animations: Animations contain a lot of visual information and contribute to the flow and artistic composition of non interactive sequences in games (i.e. cut scenes) as well as all the game world and characters. Game UIs often make heavy use of animation.
Interoperability with Direct3D: If you are creating a 3D game, the chances are that you’ve already been using Direct3D. Therefore it is crucial that what you do with your 2D API works nicely with Direct3D.

Direct2D is really great for addressing these issues. All drawings in Direct2D happen in a continuous float space, with the ability to apply transformation matrices with a few lines of code. Direct2D also gives you a lot of power for rich animation by providing very fast animation methods for transforms and by minimizing graphics bus traffic with the use of mesh and mask capabilities. Direct2D is further designed to interoperate well with Direct3D. By using Direct2D, you can directly render into Direct3D textures and use those textures to wrap your 3D models. For more information about Direct2D, see http://msdn.microsoft.com/en-us/library/dd370990(VS.85).aspx.

The Graphimation Framework Basics

During the development of Direct2D, I had the opportunity to actually apply some of these ideas to a prototype scenario. Once I recognized the value Direct2D has for the mentioned application spaces, I decided to design an animated 2D graphics framework in native C++, called the Graphimation Framework. I then used the framework to create three applications to showcase what you can do with the framework.

Direct2D Demo: A non-interactive demoscene-style demo.
Carousel: A modern animated UI prototype that has arbitrarily-shaped widgets.
D2DRTS: A simple real time strategy game.

With the ease of use and direct applicability that Direct2D possesses, I was able to implement these applications in about 4 weeks.

Disclaimer: All the code and documentation for Graphimation Framework is provided to the developer community as an example and is not an official Microsoft product. You can access the download at: http://code.msdn.microsoft.com/graphimation

Graphimation Framework

Let’s take a closer look at what the Graphimation Framework provides. It provides an interface called IGraphimation. This interface encapsulates a graphics object that can be rendered and includes some animations. It can also provide some named variables that its client can set to customize certain aspects of the graphimation object. You can also hit test against a graphimation.

A graphimation object is defined and initialized by an external file (a .d2g file). Once a graphimation object is initialized, you need to call render() on it from your render function, and update() it with time passed between each invocation of the main loop.

Each graphimation object (for example, a soldier in the RTS game) defines one or more animations. Through the render + update mechanics, each animation automatically keeps playing. Animations can also loop or tie into other animations. All this is automatically handled by the Graphimation Framework. The client can switch any animation. For example, to make a soldier walk, the application calls PlayAnimation(“walk”).

If you want to see more information about how to create and use graphimations, see the GraphimationFrameworkManual.docx file in the Doc folder in the sources. It provides information about the internal workings of the framework.

.d2g files

All the graphics and animations are defined in the d2g files. A d2g file defines the following:

Resources, such as geometries, brushes, and transforms.
Render functions, such as Fill, Stroke, and PushTransform.
Controllers that can be bound to variables, such as linear and sinusoidal.
Named animations, such as

a render function that refers to resources to render stuff,
and a main controller (that can include other controllers) tied to variables which cause the “change” in animations.

In a d2g file, you can put a variable name almost anywhere that you can write a constant number. These variables can then either be set from outside the framework by the SetVariable interface or internally controlled by a controller.

A graphimation object can also contain other graphimation objects as resources and render or update them. Therefore whole hierarchies of graphimation objects can be built and easily controlled. In fact, the entire Direct2D Demo is a single graphimation object that includes many others (like the fish, the plants, and the butterfly). Check out the manual for advanced techniques in using graphimations. Also please refer to the manual for further info on the d2g file syntax.

Framework Library Dependencies and Implementation Details

Implementing this framework was very easy with Direct2D and took only about two-dev weeks. A large portion of the code is for parsing the d2g files. Since Direct2D maps to this problem so well, the rest of the code is just simple wrapper classes around Direct2D classes with ten – twenty lines of code each.

Library Dependencies

Graphimation Framework depends pretty heavily on STL and Boost. The Graphimation Framework only needs the headers from the Boost libraries, so you only need to download Boost—you don’t have to build it. You do need to add the Boost path to your include path in Visual Studio.

You also need the Windows 7 SDK, which is available at http://msdn.microsoft.com/en-us/windows/bb980924.aspx.

As Graphimation is provided as a Visual C++2008 project, you also need a version of Visual Studio 2008. The free express one from http://www.microsoft.com/exPress/ will do.

Implementation Details and Class Diagrams

Throughout the framework the RAII concept is used to control all the resources, so the framework satisfies the “basic exception safety” guarantee that no resources will be leaked on the face of exceptions (which may happen due to STL, Boost, or new -- GXM also converts D2D errors into exceptions too). However, the framework does NOT provide “strong exception safety,” meaning that, in the case of an exception, the object may not be in a usable state. Finally, any exceptions thrown from Boost or STL are caught at the module boundary and converted to error codes. Therefore, the client code does not see any exceptions.

The following diagram shows a group of main classes and their relationships.

Samples Using the Graphimation Framework

Here I describe three samples that use the Graphimation Framework:

Direct2D Demo: a non-interactive demoscene style demo.
Carousel: a modern animated UI prototype that has arbitrarily-shaped widgets.
D2DRTS: a 2D real-time strategy game prototype.

The Direct2D Demo

By using the framework, I implemented a simple player that can play a .d2g file, and then created a set of nested .d2g files that made up a demoscene style demo. You can see what is shown in the following screen shot by running the demo.bat file in the GxmPlayer sources.

Carousel Widget Library

By using this framework, I implemented an animated UI framework prototype called Carousel with only a few hundred lines of code. Simply each widget has a corresponding Graphimation object that can be animated in different ways. For example, the following screen shot shows several parent and child widgets,

When a parent widget is clicked, child widget graphimations simply play an animation (they “open up” around their parent). The idea was providing menu navigation with minimum distance of mouse movement. All options in a menu are at a small distance from where your mouse is, thanks to the circular structure of the menus. Another interesting point is that, since Direct2D provides hit testing with arbitrary geometries, your widgets do not have to be rectangular. The Graphimation Framework provides hit testing for any sub resources it contains.

D2DRTS - A 2D Real Time Strategy Game Prototype

Writing a simple RTS game became a lot easier with the Graphimation Framework. As mentioned before, the soldiers are instances of the same graphimation type (i.e. the same .d2g file). They support a set of animations (stand, walk, fight, die etc.) and once all the graphical concerns are handled by the Graphimation Framework, the remaining game code is greatly simplified. In the example shown in the following screen shot, all I did was to implement a few classes for the game world, soldier and AI, and it only took a few hundred lines!

Conclusions

Of course a real UI framework, a real game, or a real demoscene demo will need to be more complex, but these examples help show how easy it can be to build a 2D graphic animation framework with Direct2D and be able to reuse it in a variety of cool applications.

In summary, this blog post provided a perspective on the applicability of Direct2D on certain sets of applications. A set that is not necessarily the one that comes to mind when speaking of Direct2D. Irrespective of which industry you develop software for, if your problem domain includes issues like “animated 2D graphics” and “a continuous 2D float coordinate space”, then you might enjoy a number of benefits from using Direct2D.

Bilgem Cakir, Direct2D Team

Talks from PDC 2009 now available!

2009-11-25T20:00:00Z

PDC this year had two sessions on DirectX technologies. If you attended them: thank you! For those who weren’t able to attend, the good news is that the sessions are now available online for viewing.

“Advanced Graphics Functionality Using DirectX” is about Direct2D and DirectWrite, and builds atop last year’s “Introducing Direct2D and DirectWrite” PDC talk. The second is “Modern 3D Graphics Using Windows 7 and Direct3D 11 Hardware”, and is about Direct3D 11, WARP, and Direct3D 10 Level 9.

As always, we appreciate comments and suggestions for future blog posts.

Internet Explorer announces to use DirectWrite & Direct2D!

2009-11-18T15:00:00Z

Today, the Internet Explorer (IE) team announced they will be using DirectWrite and Direct2D for IE9! Channel 9 takes us through to the halls of IE team, and shows a sneak peek at what they have in store for IE9.

Update: check out the IE team blog for their post on this announcement!

Working Around Problems in ID2D1Bitmap's CopyFromBitmap and CopyFromRenderTarget

2009-11-17T14:50:00Z

Developers using the ID2D1Bitmap::CopyFromBitmap and ID2D1Bitmap::CopyFromRenderTarget APIs may notice problems when the source and destination rectangles are of different sizes. In particular, the source rectangle is incorrectly clipped against the destination bounds (instead of against the source bounds). The destination rectangle is correctly clipped against the destination bounds.

Terminology: Since the problem in each API is very similar, it is helpful to talk about both problems at the same time. However, in order to do that, we need a common word to refer to either a bitmap or a render target. This post will use the term “Surface”.

There are two possible manifestations of this problem:

1. Access violation (crash)

This happens when you pass a source rectangle that exceeds the bounds of the source surface but the destination surface is smaller than the source surface. The clipping will be insufficient and may result in a crash. In this case applications can work around this problem by sanitizing their inputs – don’t pass source rectangles that exceed the bounds of the source surface.

2. Over-clipping

This happens when you pass a source rectangle that doesn’t exceed the bounds of the source surface but does exceed the bounds of the destination surface. The clipping will be overly zealous and less data will be copied than requested. In this case there are three possible workarounds:

a) Use D3D

Since the problem is in D2D customers using D3D and D2D together can call the corresponding APIs on the D3D interfaces. This is the option with the best performance, but it may be cumbersome to code in some scenarios. It requires that all associated D2D bitmaps to have been created with ID2D1RenderTarget::CreateSharedBitmap (IDXGISurface variant) and all associated D2D render targets to have been created with ID2D1Factory::CreateDxgiSurfaceRenderTarget. For example:

IDXGISurface *pSurface;

ID2D1Factory *pFactory;

…

ID2D1RenderTarget *pRenderTarget = NULL;

if (SUCCEEDED(pFactory->CreateDxgiSurfaceRenderTarget(

pSurface,

D2D1::RenderTargetProperties(

D2D1_RENDER_TARGET_TYPE_DEFAULT,

D2D1::PixelFormat(

DXGI_FORMAT_UNKNOWN,

D2D1_ALPHA_MODE_PREMULTIPLIED))

&pRenderTarget))

{

// <Snip> Your render target code goes here.

ID2D1Bitmap *pBitmap = NULL;

if (SUCCEEDED(pRenderTarget->CreateSharedBitmap(

__uuidof(IDXGISurface),

pSurface,

D2D1::BitmapProperties(

D2D1::PixelFormat(

DXGI_FORMAT_UNKNOWN,

D2D1_ALPHA_MODE_PREMULTIPLIED)),

&pBitmap))

{

// <Snip> Your DXGI surface manipulation code goes here.

pBitmap->Release();

}

pRenderTarget->Release();

}

These two APIs create D2D objects that wrap D3D textures. An application can hold on to the underlying D3D textures and call the ID3D10Device::CopySubresourceRegion API instead of the ID3D1Bitmap::CopyFromBitmap/ID2D1Bitmap::CopyFromRenderTarget APIs. If you choose this route, make sure you call EndDraw on all associated render targets first (including render targets against which drawing operations involving the bitmaps have been issued).

b) Use an intermediate bitmap

This option is flexible, but it is costly from a performance standpoint (in terms of both memory footprint and speed). If you are attempting to copy from an ID2D1HwndRenderTarget, this is your only option. Create an intermediate bitmap the same size as the source surface. Call CopyFromBitmap / CopyFromRenderTarget to copy the desired region to the upper-left corner of the intermediate bitmap. Then copy from the upper-left corner of the intermediate bitmap to the destination. Even though this requires copying between surfaces of different sizes as the final step, this copy is from the upper-left corner, which ensures that the source rectangle will be within the destination bounds, so it will not be affected by the clipping.

c) Use a DrawBitmap call instead of CopyFromBitmap/CopyFromRenderTarget

This option is not as flexible as option 2, but in some cases it will be less costly from a performance standpoint. The DrawBitmap API allows you to specify both a source and a destination rectangle so you can use it instead of CopyFromBitmap/CopyFromRenderTarget, provided that the destination is a render target and that the source is a bitmap. You can create a surface that is both a render target and a bitmap using the ID2D1RenderTarget::CreateCompatibleRenderTarget API. You will not be able to use this option if you wish to copy from an ID2D1HwndRenderTarget. It is not possible to create a surface that is both an ID2D1HwndRenderTarget and an ID2D1Bitmap.

We know that these workarounds are inconvenient to our customers. We hope that by sharing this information we help to minimize this inconvenience.

Windows Imaging Component: Working with Images in Windows

2009-11-13T00:22:00Z

What is it?

Windows Imaging Component (WIC) API enables applications to work with all common image formats. It allows developers to not have to understand intricate details of the image formats they work with. WIC has built-in support for popular formats such as JPEG, PNG, TIFF, and GIF as well as an extensibility model so that developers can create their own WIC decoder and encoder (CODEC) and get platform level support for their image format. WIC is available on Windows XP (SP2 and greater), Windows Vista, Windows Server, and Windows 7.

Why is it useful?

WIC is designed to handle any scenario that requires decoding or encoding an image. WIC has been widely adopted by developers inside and outside of Microsoft in their applications. The key benefits for using WIC are:

1) Fast performing CODECs – WIC has been extensively tested and tuned to provide the fastest imaging CODECs on Windows.

2) Extensive format and CODEC functionality support –WIC supports all major image formats in box and provides an extensibility model for additional formats. WIC also supports common image manipulation operations such as image rotation, scaling, cropping, and pixel format conversion.

3) Security Testing – WIC has also been thoroughly testedto be secure against malformed image data. Furthermore, since WIC is a core Windows component, it is updated as necessary to be compliant with the latest standard and security requirements.

4) Interoperation with modern DirectX APIs such as Direct2D and the Windows Color System - Direct2D provides APIs that can consume WIC objects for rendering and encoding images, this makes using WIC with D2D very easy. The Windows Color System has similar APIs available.

Because of these features, WIC is used in a variety of applications. Also GDI+ in Windows 7 uses WIC CODECs to work with images. Since a large number of applications use WIC, a consistent experience working with image formats is available for Windows Applications. For example, the chances of CODEC incompatibility issues occurring between applications that use WIC to encode and decode images are small.

How to use it?

Full documentation for WIC is available in Windows SDK and on MSDN. Links to relevant information are provided below. The code samples are a good starting point for learning how to use WIC and for accomplishing common tasks such as decoding, encoding, and reading metadata from images.

An important developer tool for using WIC is WIC Explorer which is a light weight application that exposes all the functionality available in WIC. The source code and binaries for WIC Explorer are available here. WIC Explorer exposes all available CODECs and metadata handlers installed on a system, and allows developers to see all available data in an image such as thumbnails, metadata, and actual image pixels. A screen shot of WIC Explorer is available in Figure 1 and 2.

Figure 1: Image Parameters displayed via WIC Explorer

Figure 2: Creation code for reading metadata from an image. This information is located below the image bits shown in Figure 1.

WIC Explorer is also useful for testing images and determining whether they are compliant with standards and WIC CODECs. WIC Explorer also provides reference implementation of an actual application that uses WIC. The image creation code, which is located below the image in the right pane, provides code that can be run to expose functionality, such as metadata extraction. This tool is useful for any developer that wishes to use the WIC API.

Another useful tool for developers looking to create their own WIC CODEC is WIC COP, which is available here. Documentation on how to create a WIC CODEC is available here. WIC COP is used to test custom CODECs for proper functionality, performance, and registration. WIC COP reports any problems that may exist in a custom CODEC. This tool is invaluable for developers looking to create their own CODEC.

The WIC documentation, code samples, and developer tools provide a good set of resources for learning and using the WIC API.

What new features are available in Windows 7 and Windows Vista?

In Windows 7 additional features were added to help complete scenarios for developers and to provide greater level of interoperability between applications that use WIC. All of the new WIC features are available in Windows 7 and will also be available on Windows Vista using a Platform Update download, more information is provided below. Many of the new WIC features are also explained in this informational video and in this MSDN article.

In order to support scenarios that involve working with images from the internet, support for decoding progressively encoded images was added. Progressive decoding is used to provide previews of images without having to actually download the complete image, which can often be slow. The new progressive decoding API and the feature are explained in this article and in this code sample.

Another important scenario for developers working with images from the internet is the ability to animate GIF images. WIC now supports reading and writing GIF metadata, which contains timing information necessary for animating GIF images. A code sample is available here that shows how to extract GIF metadata data and animate an image with Direct2D. WIC also supports additional TIFF formats such as JPEG encoded TIFF, Planar TIFFs, and tiled TIFFs. These image formats are created by popular imaging applications.

An important feature for any user working with digital photographs is the ability to preserve metadata across a variety of applications and platforms. By implementing the guidance of the Metadata Working Group (MWG), images edited and viewed in Windows 7 are compatible with a large variety of applications. Users can be confident that metadata added to, or read from images in Windows 7 will preserved when the image is used in, or created in an application that does not use WIC. The MWG guidelines specify metadata locations to read from and write to for common fields such as Keywords, Author, etc. Applications that use the Metadata Policy Layer in WIC for reading and writing metadata will be able to automatically take advantage of the increased metadata interoperation.

With the new features available in Windows 7 along with the ones already available since Vista, WIC is able to provide a compelling platform for working with images.

Additional Information related to Imaging on Windows

- WIC Overview

- WIC Samples (Progressive Decoding, Animated GIF, available here)

- WIC Progressive Decoding Article

- Creating a custom WIC CODEC

- WIC Explorer & WIC COP

- WIC Overview Video

- Platform Update for Windows Vista

- Device Stage – Windows 7 only

Announcing the Direct2D Debug Layer

2009-10-30T21:02:00Z

Just like Direct3D 10, Direct2D was designed to fit hand in glove with an optional debug layer that allows developers to receive rich information about design-time issues they might encounter when using Direct2D. Today, the Direct2D team is happy to announce that the debug layer is available from code gallery. For more information, and to download the layer, please see the debug layer entry in the SDK.

About the Direct2D Debug Layer

The Direct2D debug layer is an independent component that will intercept calls made from the application to Direct2D and provide feedback about various classes of errors, for example:

· Incorrect threading usage of Direct2D objects.

· Using Direct2D objects with the wrong factory.

· Incorrect parameters passed to Direct2D.

In addition, the Direct2D debug layer also provides additional warnings and informational traces about issues that an application might optionally want to address, for example:

· Using a software render target when a hardware render target might have been intended.

· Using a more expensive primitive when a cheaper one would have worked.

Using the Direct2D Debug Layer

The Direct2D debug layer is designed not to change the behavior of Direct2D when it is used. If the debug layer is installed, it will not be invoked and will not result in any performance overhead unless the application explicitly requests that the debug layer be used. To trace all issues, specify the D2D1_DEBUG_LEVEL_INFORMATION enumeration in the D2D1_FACTORY_OPTIONS structure before calling D2D1CreateFactory and run your application under a debugger.

We hope that you find the debug layer useful. We are also very happy to receive feedback about any issues you encounter during application development where you feel that a debug layer trace would have been helpful so that we can continue to improve the debug layer.

Platform Update for Windows Vista Released!

2009-10-27T22:57:00Z

The Platform Update for Windows Vista, which is in mentioned in a previous post, just had its final release! Find out more at the Windows Team Blog.

GPU Device Drivers - Driver Distribution

2009-10-22T13:00:00Z

This post will give readers insight into the GPU device driver distribution process in the Windows PC Ecosystem. Four driver distribution channels are outlined: Inbox, IHV, OEM, and Windows Update (WU). Future posts in this series will discuss driver migration from Vista -> Windows 7, hardware support for the various WDDM driver models and DirectX version levels, and how these differences affect DirectX developers.

Why care about drivers?

Every device on a Windows PC has its own driver: Network, Audio, Storage, USB, GPU, etc. Many customers don’t know what a device driver is while others update their drivers each month to get improved performance, reliability, and compatibility with the latest games and applications. We consider the entire spectrum of customers when supporting the Windows PC ecosystem. In order to coordinate Microsoft’s support strategy for these customers with our OEM and IHV partners, the Windows PC Ecosystem has four driver distribution channels which we’ll discuss below.

Driver Distribution Channels

Inbox drivers

Microsoft provides GPU drivers on the Windows 7 retail DVD on behalf of our top GPU IHV partners (AMD/ATI, Intel, and Nvidia). These drivers provide baseline functionality for about 75% of the GPU marketplace so that customers can have an easy out-of-box setup experience. These drivers are designed and written by the IHV, but are integrated into Microsoft’s development and test engineering processes to ensure compatibility. In addition, the integration of these drivers into the Windows build actually accelerates the OS development process itself because it allows us to identify and resolve issues more efficiently. Some technologies such as OpenGL, CrossFire, SLI, and Hybrid/switchable graphics are absent from the Inbox driver. (For more information on why certain technologies lack Inbox support, please see the Windows 7 Graphics Guide.)

GPU devices that do not have Inbox drivers are covered by WU which we’ll discuss later. If no inbox or WU driver is available, Windows will load the Standard VGA driver provided by Microsoft which implements the VESA standards. For most systems, this driver will deliver the common display resolutions on a single monitor, the Windows Basic theme without Aero, and limited power management support so the display is still usable. Below is a summary of GPU support available on the Windows 7 retail DVD.

IHV	Inbox Driver Version (INF)	Devices Supported	Desktop/Notebook
AMD	8.56.1.0015	Radeon 9500 -> Radeon HD 4870	Both
Intel	8.15.10.1749	GMA 950 -> GMA X4500	Both
Nvidia	8.15.11.8593	GeForce 6xxx -> 9xxx, GeForce GTX2xx, Quadro (some)	Desktop Only (*Notebook support provided by Verde program)

IHV drivers

The Inbox drivers provide a good baseline, but IHV’s continue to innovate and improve their products through new hardware releases and driver updates. IHV drivers may be downloaded directly from vendor websites such as www.amd.com, www.intel.com, www.nvidia.com, or loaded from a disc included in a retail package. Compared to Inbox drivers, IHV-supplied drivers are updated on a regular basis and tend to have more bug fixes, performance tweaks, and extra features such as OpenGL, CrossFire, SLI, and advanced control panel applets. Windows PC enthusiasts and hardcore gamers download the latest IHV drivers to get the best performance and compatibility with games and graphics intensive applications. For example, ATI, Intel, and Nvidia all list compatibility bug fixes and performance improvements in their latest driver release notes. Most driver updates are not necessary for most customers. But for major reliability fixes which eliminate blue screen errors or TDR hangs, IHV’s can post their drivers on WU as optional downloads and can request they be offered to customers as important updates, when applicable. This delivery mechanism allows the driver to get into the hands of many more customers as we’ll explain later.

OEM drivers

OEMs such as HP and Dell typically include customized GPU drivers on their systems which are tested exclusively with the particular hardware platform. These drivers are pre-loaded on the hard drive of shipping systems but can also be downloaded from OEM support websites. Laptop drivers typically have dozens of customizations specific to the hardware feature set and a driver INF file which associates the driver package with the exact PNPID of the hardware device.

The PNPID-level customization allows more control over driver distribution. For example, if a customized OEM driver is installed, WU will not offer end-users a generic or IHV-supplied WU driver unless it is specifically targeted for the user's system by the OEM. This scheme gives OEMs more end-to-end control over their products and streamlines product support by reducing the variability in the driver versions that can be installed. This reduced variability helps the OEM maintain a reliable and consistent experience for their customers. But there is a tradeoff: IHV’s continue to innovate with regular driver updates, but many OEM customers are not able to get those updates since the OEM won’t necessarily post them right away.

WU drivers

WU drivers provide baseline support for GPU devices which do not have Inbox drivers. If a customer is using the default Standard VGA driver after OS install or after installing a new video card, the WU client will automatically check the WU servers to see if a better driver is available for download. Depending on which WU options have been previously set on the machine, the driver may download and install automatically, or the customer may be prompted to accept the download. As new devices are released to market, IHVs and OEMs will continue to post drivers on their own support web sites and WU.

WU also provides a mechanism to widely distribute fixes for customer issues with previously installed drivers. End-users may not know about IHV or OEM websites or may not have the technical expertise or confidence to manually install drivers. So Microsoft works closely with OEM and IHV partners to address known issues and deliver updates automatically via WU. When a partner has a new driver update ready, they can post the driver as an optional download on WU. After several days of customer downloads, Microsoft analyzes reliability trends using opt-in customer feedback tools such as Windows Error Reporting. In fact, the use of these tools enables Microsoft to track reliability on all drivers regardless of the distribution channel. The data is analyzed and aggregated so noteworthy trends can be shared with IHV and OEM partners allowing them to target fixes more effectively. Based on this deep analysis, Microsoft may promote optional driver downloads to important downloads so that more customers get the fixes automatically.

Conclusion

We hope this post sheds some light on the driver distribution process for the Windows PC Ecosystem. Stay tuned for follow-up posts describing driver migration from Vista -> Windows 7, hardware support for the various WDDM driver models and the DirectX version levels. In the meantime you can look at the cardcaps.pdf document included in the latest DirectX SDK for a breakout of DirectX capabilities vs. GPU device.

New DirectX MSDN Developer Center

2009-10-19T13:00:00Z

Today I am pleased to announce the new DirectX MSDN Developer Center. This new site is a complete overhaul of the developer center to make it easier for developers to find the content they are looking for. Using this new site, we hope to provide the best developer content for developers making great graphics applications on a regular basis.

Right from the front page you’ll see the new design pushes the important content right to the front, including downloads, FAQs, documentation, and of course this blog J One major change with the site is that the majority of content is now provided through RSS feeds, so if you want to get the latest and greatest downloads or code samples the moment they’re available, you can easily subscribe to any feed by clicking the orange RSS button .

We know that code samples are an important way for developers to learn the ins and outs of our technologies, so we are working to simplify the way developers can get the code samples for DirectX. To this end, many of our important code samples have been made available on Code Gallery for direct download. In addition, we have a showcase of the latest DirectX tutorials right on the front page.

As always, the Developer Center will provide easy access to all of our documentation. We are constantly looking for ways to improve your experience using this documentation in your development of applications, so please let us know if you have any feedback.

Thanks for reading, and I encourage you to check out the new site! Stay tuned, as we have even more underway to improve the way you access developer resources for DirectX, including forum improvements and new content!

Michael Oneppo

PM, DirectX

Comparing Direct2D and GDI

2009-09-29T04:17:00Z

Direct2D and GDI are both immediate mode 2D rendering APIs and both offer some degree of hardware acceleration. This tends to cause some confusion – Why are these APIs different? How are they similar? Does Direct2D make GDI faster? How is Direct2D hardware acceleration different to GDI hardware acceleration? The goal of this post is to provide some insights into the differences between Direct2D and GDI.

Figure 1 - Direct2D compared to GDI

How are Direct2D and GDI different?

Direct2D and GDI are different in the details of what each API renders and how it goes about driving the display hardware. They are also somewhat different in their underlying design principles.

GDI renders opaque, aliased geometry (paths, lines, etc). It renders aliased and ClearType text, and can support transparency blending through the AlphaBlend API. However, its handling of transparency is inconsistent. Most APIs simply ignore the alpha channel, some use it. Very few APIs guarantee what the alpha channel will contain after an operation. Perhaps more importantly, GDI’s rendering doesn’t map easily to what a modern GPU renders most efficiently on the 3D portion of its rendering engine. For example, ROPs can’t be implemented by the blend stage of a GPU. However, alpha can. (ROPs can be implemented by copying between render targets and using look up tables or bitwise operations in the pixel shader. However, this is still slower than using the blender stage of the hardware). As another example, Direct2D’s aliased lines are designed to be implemented simply as two triangles rendered on the GPU. GDI guarantees that Bresenham’s line drawing algorithm is used.

Direct2D renders opaque, transparent, aliased and anti-aliased primitives. It has strict guarantees on how it both accepts and renders transparent content. This makes designing a modern UI with Direct2D easier and, it also allows Direct2D to render all of its primitives using hardware acceleration. Direct2D is not a pure superset of GDI – primitives that would have been unreasonably slow to implement on a GPU aren’t present in Direct2D. This should at least answer one question - Direct2D doesn’t help improve the performance of GDI, since GDI doesn’t use Direct2D. Neither does Direct2D use GDI.

How Direct2D and GDI differ in terms of architectural layering is shown in Figure 1. Direct2D uses Direct3D to obtain hardware acceleration. Direct3D in turn uses a user-mode display driver which packages up command streams. Direct3D sends these command streams and resources down into kernel mode for the hardware to process.

One large advantage of this architecture is the ease with which an application can use both Direct2D and Direct3D together.

Since Windows NT 4, GDI has run in kernel mode. The application calls GDI which then calls its kernel mode counterpart. There, GDI passes the primitives to its own driver model. This driver then sends the results to the global kernel mode display driver. Since around Windows 2000, GDI and the GDI drivers have run in an independent space in the kernel called “session space.” A session address space is created for each logon session and each instance of GDI runs independently in this distinct kernel mode address space.

How are GDI and Direct2D Hardware acceleration different?

The most important difference between Direct2D and GDI hardware acceleration is that Direct2D is layered on top Direct3D, while GDI has its own independent notion of a driver model. This driver model (the GDI Device Driver Interface or DDI) corresponds to the GDI primitives, while the Direct3D driver model corresponds to what the 3D rendering hardware in a GPU renders. When the GDI DDI was first defined in the early 90’s most display acceleration hardware targeted these GDI primitives. Over time, however, more and more emphasis was placed on 3D game acceleration and less on application acceleration. As a consequence more of the GDI DDI wasn’t implemented by the display driver and in the end, BitBlt was accelerated and most other operations were not.

This set the stage for a sequence of changes to how GDI renders to the display. The sequence is shown in Figure 2. There were also a number of additional factors that caused changes to the GDI driver model.

Increasing complexity and size of display drivers

Over time display drivers became more complex due largely to the increasing complexity of the 3D portion of the driver. Higher complexity code tends to exhibit more defects; hence it was desirable to move the driver to user-mode where a driver bug wouldn’t cause a reboot. As can be seen in the figure, the display driver has been divided into a complex user mode component and a simpler kernel mode component.

Figure 2 - Evolution of GDI display rendering

Difficulty in synchronizing session and global kernel address spaces

In Windows XP a display driver exists in two different address spaces, session space and kernel space. Some parts of the driver need to respond to plug ‘n play and power management events. This state needs to be synchronized with the driver state in the session address space. This is a difficult task and display drivers tended to exhibit defects when attempting to deal with these distinct address spaces.

The composited desktop

The composited desktop required GDI to be able to render to a surface which was then rendered by Direct3D to display. This couldn’t be done easily in the XP driver model since GDI and Direct3D were parallel driver stacks.

As a result, in Windows Vista, the GDI DDI display driver was changed to be only implemented by a Microsoft supplied driver, the Canonical Display Driver (CDD). GDI rendered to a system memory bitmap. Dirty regions were used to update the video memory texture which the window manager uses to composite the desktop.

GDI rendering in Windows 7

The chief disadvantage of the windows vista driver model was that every GDI window must be backed by both a video memory surface and a system memory surface. This results in system memory being used for each open GDI window.

For this reason GDI was changed again in Windows 7 to ensure that it does not require a system memory surface per window. Since GDI rendering requires it to read, modify and write the system memory surface, and since the CPU cannot directly access video memory, GDI was modified to render to and from a piece of aperture memory. The aperture memory can be updated from the video memory surface holding the window contents. GDI can render back to the aperture memory, and the result can then be sent back to the window surface. Since the aperture memory segment is addressable by the GPU, the GPU can accelerate these updates to the video memory surface. For example: text rendering, BitBlt with common ROPs, AlphaBlend, TransparentBlt, StretchBlt are all accelerated in these cases. In addition, some operations can bypass the aperture memory segment entirely, such as window BitBlt and ColorFill.

Contrasting Direct2D and GDI acceleration in Windows 7

Direct2D and GDI are both 2D Immediate-mode rendering APIs and both can be described as hardware accelerated. However, there are a number of differences that remain in both APIs.

Location of resources

GDI maintains its resources, in particular bitmaps, in system memory by default. Direct2D maintains its resources in video memory on the display adapter. As a result, when GDI needs to update video memory, this must always be done over the bus, unless the resource happens to already be copied into the aperture memory segment, or if the operation can be expressed directly.In contract, Direct2D can simply translate its primitives to Direct3D primitives because the resources are already in video memory.

Method of rendering

In order to maintain compatibility GDI performs a large part of its rendering to aperture memory using the CPU. In contrast, Direct2D is a translator that translates its APIs calls into Direct3D primitives. The result is then rendered on the GPU. Some of GDI’s rendering is performed on the GPU when the aperture memory is copied to the video memory surface representing the GDI window, or when it is otherwise possible.

Scalability

Direct2D’s rendering calls are all independent command streams to the GPU. Each Direct2D factory represents a different Direct3D device. In contract, GDI uses one command stream for all of the applications on the system. GDI’s method can result in some amortization of GPU and CPU rendering context overhead. Direct2D’s approach has little unnecessary serialization between independent command streams.

Location

Of course, Direct2D is entirely in user mode, including the Direct3D run time and the user mode Direct3D driver. GDI, in contrast, has most of its functionality in session space in kernel mode, with its API surface in user mode.

Availability of Hardware Acceleration

GDI is hardware accelerated on Windows XP, and on Windows 7 when the DWM is running and when a WDDM 1.1 driver is in use. Direct2D is hardware accelerated on any almost any WDDM driver and regardless of whether DWM is in use. There are announced plans to port Direct2D to Windows Vista. Here it will also be hardware accelerated on almost any WDDM driver. On Vista, GDI will always render on the CPU.

Presentation Model

When Windows was first designed, there was insufficient memory to allow every window to be stored in its own bitmap. As a result, GDI always rendered logically directly to the screen, with various clipping regions applied to ensure that it did not render outside of its window. In contract, Direct2D follows a model where the application renders to a back-buffer and the result is atomically “flipped” when the application is done drawing. This allows Direct2D to handle animation scenarios much more fluidly that GDI can.

Conclusion

We hope this post gives you some insights on how GDI and Direct2D work. If you have existing GDI code, that will continue to work well under Windows 7. But if you are writing new graphics rendering code, you should consider using Direct2D to leverage modern GPUs better.

For more information on interoperability between Direct2D and GDI see the following:

· A previous blog post on Direct2D interoperation

· The SDK article on Direct2D and GDI interoperation

D3D9d.dll from March 2009 DirectX SDK mismatch with Windows 7 RTM

2009-09-14T21:01:00Z

If developers are using the debug version of D3D9 runtime d3d9d.dll from March 2009 DirectX SDK, they may notice compilation or runtime errors when developing on Windows 7 RTM.

There is a binary mismatch between d3d9d.dll from March 2009 DirectX SDK and Windows 7. To workaround, developers should be using the latest August 2009 DirectX SDK.

Using Direct2D for Server-Side Rendering

2009-09-11T20:16:00Z

Some server applications need to render for scenarios like charting and sending back the generated bitmaps to users connected through web clients. During the planning of Direct2D, we decided to put the support of this scenario as one of our design goals.

Requirements of server-side rendering

There are several specific requirements for this scenario. First, usually the process is going to be run in Session 0 for security reason. Session 0 is dedicated for system processes and services, and isolated from user applications. It has higher privilege in some aspects but no privilege in interactive features (details here). Second, most servers only have low-end graphics cards, or there may even be no graphics cards inside, thus the availability of hardware acceleration cannot be expected. Third, the application should be able to handle multiple concurrent requests efficiently on a multi-core machine.

Options of available APIs

There are three native 2D rendering APIs that applications can use in Windows Server 2008 R2: GDI, GDI+ and the new Direct2D. I will go through each of them and talk about whether they fit with this scenario.

GDI
GDI does not support high-quality drawing. It lacks the support of anti-aliasing, which makes sloped lines jaggy. Moreover, it does not have full support for transparency, such as the support of semi-transparent brushes and pens.

GDI was not designed for parallel processing and suffers from an inefficient global lock. Windows 7 and Windows Server 2008 R2 have redesigned this lock to be more granular (details here), but based on our test results, D2D still scales better.

Another problem is that the total number of GDI handles is limited to 10240 per process and 65536 per session, because internally Windows uses a 16-bit WORD to store the index of them for each session. Stock objects are excluded from this limitation. Spawning new sessions is one way to overcome the limit, but it increases the memory usage.
GDI+
The main problem with GDI+ for server scenarios is that it does not officially support running in Session 0. Functions that try to interact with the display device will receive errors because it is not allowed in Session 0. Other functions may also fail because even if the function doesn’t seem related to the display device, it may use some paths underneath that are forbidden.

GDI+ supports anti-aliasing and alpha-blending, thus it doesn’t have the quality issue of GDI. However, there is also a performance issue due to the locking mechanism, and no work in Windows 7 or Windows Server 2008 R2 has been done to improve it in GDI+.
Direct2D
D2D was designed with multi-threading and Session 0 in mind from the very beginning. In most multi-threaded cases, D2D can be lock-free by using multiple single-threaded factories, one for each thread. There will be a factory-wide lock if the application has to use the multi-threaded mode of the factory, but it is more granular than those in GDI and GDI+. The impact of this lock is negligible and won’t grow exponentially when the number of threads increases.

How to use Direct2D for server-side rendering

A typical server application for this scenario will generate pictures inside the memory using D2D software rendering using multiple threads where each thread draws one picture.

Software rendering
To use D2D on a server without hardware acceleration, the key step is to use the software rasterizer by creating a WIC bitmap render target with D2D1_RENDER_TARGET_TYPE_SOFTWARE or D2D1_RENDER_TARGET_TYPE_DEFAULT. The default property will also use software rendering because WIC bitmap render target does not support hardware rendering.
Multi-threading
Usually a multi-threaded architecture is good for server rendering. Take a banking application that generates charts for example. The typical case is that there will be many users connected to the server at the same time, and the charts they are asking for can be generated independently. When running on a multi-core server machine, it would be very efficient to create multiple rendering threads and put one charting task to each thread, so that the OS can fully utilize the CPU cores to run rendering tasks in parallel.

One concern about the design of multi-threaded architecture for D2D is how to create and share factories and render targets across threads. The following figures show three different potential approaches.

Figure 1 shows different threads sharing the same factory and render target. This architecture is dangerous even if the factory uses multi-threaded mode. The internal lock does not prevent situations like overlapping BeginDraw() and EndDraw() to the same render target, as depicted in the picture. The BeginDraw() in thread 1 will fail because the render target is being used for the drawing of thread 2. We do not support this architecture since it’s unpredictable when multiple threads are changing the state of the same render target simultaneously, e.g. setting the transformation matrix.

Figure 2 works but only has the same performance as single thread. The D2D locking in multi-threaded mode factory is in function level and all the D2D calls in the same factory will be serialized. As a result, if thread 1 tries to enter a D2D function while thread 2 is in the middle of executing another function, thread 1 will be blocked till thread 2 finishes.

Figure 3 is what we suggest for server-side rendering. A separate factory is created for each thread. The factory can be put in single-threaded mode if it’s only going to be accessed from within the thread. D2D functions in different threads are lock-free and can run in parallel. The cost of having multiple factories is much less than creating multiple D3D devices, just about 60k each for the memory.

Although Figure 3 has the best concurrency, you may consider Figure 2 for the benefit of sharing D2D resources that are created from the same factory.
Generate an image file
Here are the main steps to generate an image file:
1. Create an IWICBitmap,
2. Pass the bitmap to CreateWicBitmapRenderTarget(),
3. BeginDraw(),
4. Use ID2D1RenderTarget::Clear() to clear the background. To have a transparent background in the output picture, use a color with 0 in the alpha channel for this function.
5. Draw to the render target,
6. EndDraw(),
7. Set up an IWICStream that either writes to a file (InitializeFromFilename) or writes inside the memory (InitializeFromMemory),
8. Use IWICBitmapFrameEncode to encode the bitmap into the picture format you want.
For a detailed example see the Save as an Image File Sample on MSDN.

Conclusion

As you can see above, using Direct2D for server rendering is simple and straight-forward. It provides high-quality and highly-parallelizable rendering that can be run in low privilege environments of the server. More information about how to use Direct2D can be found on MSDN here.

The Platform Update for Windows Vista

2009-09-10T12:15:00Z

Today on the Windows Team Blog we announced the Platform Update for Windows Vista. This is a set of runtime libraries that makes it easy for developers to target both Windows 7 and Windows Vista. I am very pleased to tell you that the Platform Update for Windows Vista includes the new DirectX package, including DirectWrite, Direct2D, Direct3D 11, updates to the Windows Imaging Components, XPS Print API, XPS Rasterization Service, and DXGI 1.1, enabling all new DirectX technologies on Windows Vista as well as Windows 7. In addition, the package provides several other libraries for Windows Vista for ISVs and developers that are transitioning to Windows 7 that make it easier to target and support a mixed customer base of Windows 7 and Windows Vista-based systems.

Feature	Description
Windows Graphics, Imaging, and XPS Library	Latest iteration of the DirectX platform: Direct3D 11, Direct3D 10 Level 9, WARP, Direct2D, DXGI 1.1, DirectWrite, Windows Imaging Components, and XPS Print API, XPS Rasterization Service.
Windows Automation API	Allows accessibility tools and test automations to access Windows user interface in a consistent way across operating system versions.
Windows Portable Devices Platform	Supplies the infrastructure to standardize data transfers between an application and a portable device, such as a mobile phone, digital camera, or portable media player.
Windows Ribbon and Animation Manager Library	Includes the Windows Ribbon API, a command framework that enables developers to quickly and easily create rich ribbon experiences in their applications, and the Windows Animation Manager API, an animation framework for managing the scheduling and execution of user interface element animations. The Windows Animation Manager API can be used with any graphics platform including Direct2D, Direct3D, or GDI+.

The Platform Update for Windows Vista will be supplied through Windows Update as a "recommended" install. The package requires Windows Vista SP2 or Windows Server 2008 SP2 or higher, and will be made available to the general public to download during the Windows 7 general availability time frame.

This package provides many cool features from Windows 7 onto Windows Vista in order to make sure developers can target the widest audience without having to wait for everyone to upgrade to Windows 7 in the next few months. That being said, Windows 7 is really the best experience we are providing and if you haven’t already, we recommend checking it out for yourself at our Windows 7 tour site. If you are a TechNet subscriber, you can even get the RTM version of Windows 7 early at the Windows TechNet site!

Starting Early

So what happens from now until Windows 7 general availability? We’ve set up a public beta for the Platform Update for Windows Vista to let developers try it out and for testing deployment. The public beta is also on Windows Update, but you must configure your machine to receive it. We’ve put all the proper setup procedures into a tool you can download off the Microsoft Download Center. Please refer to this download page for information and instructions.

Writing Applications

In order to create software that uses DirectX, you’ll need an SDK to properly target the technologies. Probably the fastest way is to get the DirectX SDK, which includes the headers and import libraries for most DirectX technologies. We just launched the August 2009 DirectX SDK which is available now. This is the RTM version to match Windows 7 and the Platform Update for Windows Vista, containing the first official release of the DirectX developer resources for Direct3D 11, DXGI, Direct2D, and DirectWrite. The DirectX SDK also includes a multitude of samples and tutorials for Direct3D, as well as the documentation for Direct3D and DXGI. Alternatively, the Windows 7 SDK is the best way to go to get started with the Windows Imaging Components. In addition, the Windows SDK includes documentation and code samples for Direct2D, DirectWrite, and the Windows Imaging Components. With these SDKs, developers can now publish and distribute applications and games that leverage all of the software and hardware features of DirectX in Windows 7 and Windows Vista.

Using the Platform Update for Windows Vista

Once the Platform Update for Windows Vista goes live, users who have enabled automatic updates will have the DirectX components installed automatically. This way, most Windows users on Windows Vista or Windows 7 will be ready to use DirectX content shortly after Windows 7 general availability.

However, not everyone will have Windows Update enabled on their machine. Our data indicates the number of people in this situation will be low, but if you want to target as many customers as possible it would be good to check. To help with this, we've included two resources in the August DirectX SDK: a technical article, "Direct3D 11 Deployment for Game Developers", which describes the Windows Update landscape in a little more detail and provides recommendations, and a code sample called the D3D11InstallHelper which builds into an executable that will execute the whole installation experience for you. In addition, the code sample also provides a set of APIs that allows you to kick off the installation of Platform Update for Windows Vista from within your application or installer. These resources install the entire Platform Update for Windows Vista, so although they reference Direct3D 11 in the name, rest assured that all of DirectX is covered. Check out the August 2009 DirectX SDK for details.

Thanks for reading, and we look forward to seeing the amazing applications you will make with DirectX!

DirectX Componentization and Interoperability

2009-08-26T22:15:00Z

There are many different graphics technologies in Windows, and with Windows 7 we are adding to that collection with new technologies such as Direct2D and DirectWrite. Additionally, technologies such as GDI and GDI+ continue to be used in Windows software for many applications.

As we have mentioned before, these technologies were all designed with some set of scenarios and customers in mind at some point. And many of these technologies have enjoyed success and are used by a variety of applications, some of which have a history going back more than a decade. For these reasons and more, adopting new technology typically is not done with a brand new application from scratch. Normally there is an existing body of code that either needs to be ported to a new technology, or needs to work with the new technology as seamlessly as possible.

In this post I want to cover the concept of API interoperability. For the purposes of this post, this is defined as a point in one API where resources from another API can be used. Basically, this denotes a point where the two technologies can be ‘joined together’ and is an opportunity for different versions of the same technology to work together (for example, using D3D11 with D3D10), or for technologies that do similar things to work together (for example, drawing to a GDI surface with D2D). This capability to use APIs together has always existed with DirectX, but some of the mechanisms have been more efficient than others in the past.

This post is not meant to be exhaustive – each of these points can sometimes require some depth of learning to be harnessed effectively, and future blog posts and white papers will do that. The main goal is to highlight the places where our technologies work together and discuss the philosophy we have around that moving forward.

The current landscape of DirectX technology is vast. Below is a diagram that I have created to attempt to show both existing technologies (in orange), our new / evolved technology for Windows 7 (in blue) and show an interface or method that links them together wherever possible.

Note that this “subway map” of DirectX APIs does not cover every single way of making them work together, just the main supported or advised ways of doing so. Most APIs have a way of reading and writing raw memory for surfaces, and this is always the most basic way of making two things work together. However, this method of interoperability has the weakness of not allowing good performance when video memory is brought into the picture. It also does not allow an application to take advantage of improvements in how technologies can work together over time.

There are some key concepts that should be gleaned from this diagram:

The legacy runtimes were not the best at working together. D3D10.0 had no way to talk with GDI. D3D10.0 and D3D9Ex could share surfaces, but they had to manually synchronize. This was a known pain point for developers and is hard to do, because basically you have two different runtimes both asynchronously communicating to the hardware and knowing the state of synchronization between two APIs is difficult.
The Windows 7 technologies are all linked in a common sense way. D2D was designed to consume WIC bitmaps easily and to draw DWrite text easily. D2D can render to D3D10.1 textures without doing any copying or GPU / CPU synchronization. And D3D10.1 and D3D11 can share surfaces between their devices without GPU / CPU synchronization. Going forward we want to keep our new technologies working together this way as a cohesive, componentized stack.
The new Windows 7 APIs can work together with our legacy APIs. They can all talk to GDI (with D3D runtimes doing this through DXGI). This is important because so many applications are still built with GDI, and working with GDI allows incremental use of the new technology as well as an easier port of existing technology if desired. Legacy D3D runtimes can share surfaces with the new runtimes if need be as well.

Hopefully the current state of affairs is clear – we are committed to making sure that our current APIs and technologies work together as well as they can. We know that ideally every single API will work well with any other API, but the reality is that time is limited and we chose to focus on getting the new APIs to work well with GDI, since this is a known point where people need interoperability to work. We will never reach the point where we have 100% mixing of any two APIs, because not all combinations equal sense – we want to invest more heavily in the areas that have the most demand.

There are many challenges in making interoperability fast, but there are three main factors that are responsible for creating bottlenecks:

Copying resources around in system memory – this eats memory bandwidth and CPU time, either limiting the performance or making an experience eat more resources than it should.
Moving content between the GPU and the CPU – this can tie up the system bus, and tie up resources in managing the copy. It normally also involves similar memory access problems to the normal copying.
Synchronizing GPU / CPU state – the normal mode of operation for GPU communication is asynchronous, because this increases performance by allowing batching up of commands. Synchronization involves flushing these commands and causing a CPU wait.

In the future our goal is to continue to make our technologies work better together at the API level, mainly through developing all of the components as a cohesive stack that works better together by design and works to remove the above bottlenecks as much as possible. This will be a challenge going forward, but designing this in at the beginning is easier than bolting it on later.

If there is a particular connection or set of connections in the above diagram that you would like to see more detail on, please leave a comment and let us know. More data about the detail that people want is very useful.

Paint.NET uses DirectWrite

2009-08-14T15:00:00Z

The latest alpha build of Paint.NET v3.5 is using DirectWrite instead of GDI for the Text tool if you are running Windows 7. More details and a pointer to download Paint.NET v3.5 that uses DirectWrite is available here.

Paint.NET is a graphics editing program for Windows, developed on the .NET Framework. Originally created as a Washington State University student project, Paint.NET has evolved into a powerful graphics editor with support for layers, blending, transparency, and plugins.

Managed Wrappers for the DirectX APIs in Windows 7

2009-08-13T19:35:00Z

For applications developed using the .NET framework, there is now a way to leverage the Windows 7 DirectX APIs (Direct3D10, Direct2D, DirectWrite, WIC and Direct3D 11) from your managed applications. The Windows API Code Pack is now available on MSDN. Using Windows API Code Pack you can now incorporate the power of DirectX into your applications without having to write managed-native interop code yourself.

The Windows® API Code Pack for Microsoft® .NET Framework provides a source code library that can be used to access some new Windows 7 features (and some existing features of older versions of Windows operating system) from managed code. It also includes sample applications and API reference documents. You can build the included solution files to get the assemblies for use in your applications (pursuant to the attached license). More information about the Windows API Code Pack is here.

DirectX videos on Channel 9

2009-06-16T12:01:00Z

Channel 9 offers another medium for sharing information about the Windows technologies in a developer to developer conversation format. The videos on Channel 9 are designed to provide you additional insights into the DirectX APIs (and other Windows technologies) and take a peek at the underlying architecture. Together with the blog posts and other MSDN documentation, we hope you have all the information you need to create high-quality graphics applications on Windows 7. During the past couple of months we have been working on a number of videos on Channel 9 featuring the DirectX technologies in Windows 7. The following are already live:

Windows 7 Graphics Architecture Overview – Part 1

Windows 7 Graphics Architecture Overview – Part 2

Windows 7 Graphics Architecture Overview – Part 3

Windows 7 Graphics - WIC

Windows 7 Graphics - High-DPI

Look for more videos on the different areas within DirectX in the near future. Please check them out and send us your comments.

Responding to comments - 2D drawing APIs in Windows

2009-06-10T04:32:00Z

How does Direct2D know the "best" size of texture to use for the current video card? In the future, if new cards are released that have improved performance charateristics with larger textures, how will Direct2D scale upwards?

Direct2D is a very policy free API. It creates a texture the same size as the bitmap that you ask it to create – there are no tricks done under the covers to try and glom textures together for you, or use multiple small bitmaps to make a big one. It is up to the developer to measure the performance with the bitmap sizes used.

So what' s the plan going forward? Is D2D going to be *the* 2D API, and GDI reduced to a legacy/backwards compatibility role? (please say yes). Or are the two going to live side by side, requiring you developers to switch between them depending on which task we need to do?

Short answer: Yes.

More detailed answer: There are no plans to remove GDI from the system, and there are many applications that will continue to use GDI because the cost to rewrite everything with D2D will be too high. The vision going forward is that D2D is *the* 2D API. We are very interested in any feedback that could tell us what is blocking this going forward.

Features such as ID2D1DCRenderTarget and ID2D1GdiInteropRenderTarget::GetDC were put into the system not as a signal that D2D is meant to always augment GDI, but to enable applications to be ported gradually from GDI to D2D.

By the way, how does the decision to use DX10.1 as a base impact D3D9 applications? Most apps still use that, after all. Will they be able to make use of D2D in any way?

There are two issues here. The first is hardware support – D3D10.1 ships with D3D10Level9 in Windows 7, and this allows D3D10.1 to utilize D3D9 hardware through D3D9 drivers, bypassing the D3D9 runtime entirely. This allows D2D and other applications to use the capabilities of D3D10.1 while still having reach with hardware.

The issue of using D2D to (for example) draw to D3D9 textures is something that is supported, but requires more code than using D3D10.1. This will be covered in more detail in future white papers and blog posts.

Going forward we anticipate that new applications will be written with D3D10.1 so that features like WARP can be taken advantage of.

Hi, where can I find information about when the final version of Direct2D/DirectWrite is being released? I need at least a time frame.

When will DirectX 11 be available for Vista? What is the redistributable vehicle for D3D11, D2D, DirectWrite and when will the RTM redistributable for Vista ship?

The final versions of all of the new DirectX APIs (including D2D, DirectWrite, WARP and D3D11) will ship first with Windows 7, and will be made available on Vista afterwards. We are still in the process of finalizing the dates and the logistics for downlevel - stay tuned to hear more from us. You can read more about our Windows 7 shipping plans here:

http://blogs.msdn.com/e7/archive/2009/05/11/OurNextEngineeringMilestone2.aspx

New MSDN article about Direct2D is live

2009-06-09T05:50:00Z

MSDN has just published a new article about Direct2D on its web site. The article is written by Kenny Kerr and features some insights from Direct2D team member Mark Lawrence. You can check it out here:

http://msdn.microsoft.com/en-us/magazine/dd861344.aspx

Changes in Direct2D and DirectWrite between Windows 7 Beta and Windows 7 Release Candidate

2009-05-13T22:22:00Z

If you're working on porting a project from Windows 7 Beta to work with the Windows 7 Release Candidate, there are a handful of breaking changes in Direct2D and DirectWrite that you'll need to be aware of. We've documented these changes on MSDN for reference:

2D Drawing APIs in Windows

2009-05-12T23:14:00Z

In Windows 7 we have invested heavily in building a new 2D drawing API in the DirectX family called Direct2D. This API was developed to fill several holes in our Windows graphics platform. One of the most important things to rectify was the lack of hardware acceleration for regular 2D application rendering. With the release of Windows Vista, GDI hardware acceleration was removed. We also wanted to modernize the feature set for 2D rendering with antialiasing and alpha blending support, as well as add interoperability with the other modern graphics APIs. Finally, we also wanted to ensure that server side rendering was addressed as part of developing a new API.

In order to understand how we got to Direct2D, we first look way back in history to when Windows was first developed. The original rendering system (which still exists to this day) was GDI (Graphics Device Interface). This was originally written for 16 bit Windows, but was updated for 32 bit Windows for Windows 95 and Windows NT. Since GDI was developed so long ago for computers with meager abilities, it does not have features such as anti-aliased primitives, and most APIs do not have alpha support.

Around the Windows 95 time frame, the first version of DirectX was released and DirectDraw was one of the first components. The idea here was to give even more direct access to hardware than the WinG effort allowed, which in turn meant that hardware accelerated blitting was enabled. This stack had some cooperation with GDI, but really was a parallel universe in its own right.

As graphics hardware evolved, GDI gained the ability to be hardware-accelerated through a set of DDIs (Device Driver Interface). Many video cards came to implement these DDIs, and it became commonplace to buy a video card to improve your Windows performance. Eventually Direct3D came onto the scene with DirectX 2, and also created its own set of DDIs. Video cards started to devote more and more silicon to implementing 3D graphics faster and faster to keep up with a very demanding gaming market. The result was that there were two different realms of hardware acceleration and graphics programming – one built around Direct3D and the other around GDI.

The fact that Direct3D and GDI were built up from different places with different goals meant that they did not work together as well as some people expected. Features like GetDC were implemented, which helped to bridge the gap, but there were always some frustrations with scenarios where a lot of interleaved rendering was needed. This did not remove the need for such scenarios to be solved, however.

Around the turn of the century, the limitations of GDI became more apparent. Microsoft invested in a set of extensions to GDI that would be able to fill in some of these gaps in functionality, which became GDI+. Some of these extensions included different pixel depth formats, alpha blending support in bitmap operations and brushes, anti-aliased primitive rendering and more complex primitive rendering. GDI+ also included imaging support such as the ability to open PNG and JPG files. With all of the operations that GDI+ added, though, there was no hardware acceleration support for the operations that it performed.

GDI+ enjoyed considerable popularity in the managed world because it was the workhorse of the System.Windows.Drawing namespace. Pretty much every Windows Forms application that employed custom rendering used GDI+ to do the work. But GDI+, being built on top of GDI, inherited all of the same issues with regard to Direct3D interoperability; in fact, because it was always rasterizing in software, some scenarios became even worse.

When it came time to plan Windows 7, it was clear that we needed to address the shortcomings with regard to interoperability, uneven hardware acceleration and capability. Doing this while retaining the existing APIs would have been very difficult. GDI has a very long history and a very large application compatibility space, and trying to wedge alpha blending (for example) into the core GDI API set would have been very difficult to do without risk to existing customers. Since GDI+ was built on top of GDI and had a certain preexisting contract, adding hardware acceleration to it would have been very difficult.

The solution was to create a new API that could encapsulate the functionality that we wanted, as well as take the interoperability concerns into account. The MIL code (this is the native component in WPF that does the rendering) was a convenient starting point, since it had the rendering features that were needed and provided both software rendering and hardware fallback.

One of the first things that needed to be done was to change over the rendering code to be based on D3D10.1 rather than D3D9. This decision was made since there were several other technologies being built around this version of the runtime as a basis (10level9, WARP, D3D primitive remoting), and because we see hardware built around this architecture as being the future. This allowed us to design D3D10.1 interoperability, and hence allow these other technologies to interoperate with Direct2D as well.

Another interoperability work item was leveraging work done in the window manager and in DXGI to make sure that Direct2D and GDI could work together. You can draw with Direct2D to GDI targets, as well as draw with GDI to Direct2D targets. While these features are not free from a performance perspective, they do allow applications to be built mixing the two APIs to allow people to move over to the brave new world.

A significant chunk of work that was done was to try and make the API expressive from a performance viewpoint. WPF does significant resource management on the behalf of the developer, but this is difficult to do with an immediate mode API that gives control to the developer. This might sound simple, but there are a lot of design decisions around making sure that GPU memory is not allocated without the user asking for it and still allowing people to build what they want. The design of the D2D factory and the resource / threading model that follows from it allow server side rendering to scale appropriately in a way that GDI cannot.

The way that text and imaging was approached was to leverage DirectWrite and WIC, respectively. This represents an approach that we are moving towards which is more componentized. Direct2D takes care of hardware accelerating the rasterization of DirectWrite text and hardware accelerating bitmaps taken from WIC, in a complementary fashion rather than a subsuming one.

In the end, what we have built is a hardware accelerated 2D rendering API (with software fallback) with a modern primitive rendering set that allows interoperability with previous APIs as well as the state of the art APIs. We feel that this will be a worthy replacement for GDI and GDI+ for most application development scenarios, and will also be able to complement D3D10.1 in some game development scenarios as well. The componentized fashion that was used to build the full set of technologies will also allow developers to mix and match pieces to build things that were hard to build before, such as being able to render subpixel positioned text directly into Direct3D textures with support for any font. We hope that this technology will be useful, and we would love to hear feedback on how to make it better in the future.

For more information about Direct2D, you can read the following:

MSDN Documentation: http://msdn.microsoft.com/en-us/library/dd370990(VS.85).aspx

PDC talk: http://channel9.msdn.com/pdc2008/PC18/

Welcome to the DirectX Blog

2009-04-20T23:32:00Z

Welcome to the DirectX blog! Today Windows supports a number of APIs such as GDI, GDI+, D3D etc. that often provide overlapping graphics functionality. When we started working on Windows 7, one of our goals was to rationalize our graphics APIs and at the same time update them with the features that application developers wanted. We wanted these APIs to be modular and composable with existing graphics APIs. To this end, we put together a team to be responsible for graphics in Windows. In this blog you will get to hear directly and interact with the engineers in this team.

“DirectX” originated as a brand name for Windows technologies aimed at simplifying the game development experience. DirectX bypassed the abstractions put in place for standard application development and provided the developer direct access to graphics, audio, and input hardware. This unified set of technologies provided game developers a single SDK for all their development needs. Over time, these technologies moved to be unified across many platforms provided by Microsoft, specifically the Xbox 360 and Windows. These technologies, specifically DirectInput and DirectSound, moved away from the DirectX brand and associated with the XNA brand, changing their names to XInput and XAudio. Only one technology kept the DirectX branding: Direct3D. In fact, DirectX has become synonymous with Direct3D to the extent that the PC ecosystem (Graphics IHVs, PC OEMs, Game Developers and Enthusiast end users) uses “DirectX” as a way to refer to the graphics capabilities of their machine.

On a parallel front, Windows maintained an extensive set of graphics technologies to meet the needs of application developers and the UI for the operating system. Graphics is composed of 2D, 3D, text rendering, imaging, and device management. These tasks were managed primarily though the Graphics Device Interface, or GDI. GDI managed 2D rendering, hardware-accelerated displays and display surface management, imaging, and text rendering. In Windows 2000 we also introduced a new set of APIs for similar functionality, but upgraded capabilities, called GDI+ which was not hardware accelerated.

Technology	Existing APIs
2D	GDI/GDI+
3D	D3D3…D3D10
Text	GDI/GDI+
Device Management	GDI
Imaging	GDI/GDI+/WIC

Thanks to the success of gaming, cheap and capable graphics was available in every PC and even every Smartphone. In the meantime, there developed a need for compelling and rich UI that enabled end users to interact with their PCs using intuitive ways such as with touch and to be able to visualize the profusion of digital content on their PCs in a rich way. The UI designers’ ideas to solve these problems involved taking advantage of the graphics HW to provide high quality visuals animated smoothly in the UI as highlighted in the UI of PC Operating Systems such as Vista. Very soon ISVs wanted to achieve the same level of visual fidelity and smooth animation that the OS provided for their applications’ UI.

Unfortunately the existing APIs were either lacking in modern features (e.g. Lack of Alpha and Anti-aliasing in GDI) or slow (e.g. GDI+) for such usage. Many ISVs also do not have the luxury to rewrite their applications in their entirety to take advantage of existing hardware accelerated APIs like Windows Presentation Foundation (WPF). Hence there was a need to come up with a set of graphics APIs that have the requisite performance and fidelity by using the graphics hardware and that can be used independently and interoperate with existing code-bases. Therefore, we updated some of the more recent APIs such as the Direct3D 10 API and introduced new ones such as Direct2D and DirectWrite. This updated set of graphics APIs are currently in development for Windows 7. With these new technologies, Windows will have a clean, interoperable, hardware-accelerated graphics stack for use with any application. The table below shows how the graphics functionality maps to the existing APIs and the APIs that we recommend using for Windows 7. In general, the new APIs can be substituted for the existing APIs that provide similar functionality, but there will still be cases where identical functionality does not exist in the new APIs, especially in the case of Device Management where GDI continues to be the main API for this functionality. Over time, as we receive feedback from application developers, will work to address all short comings of the new APIs.

Technology	Existing APIs	Windows 7 Component
2D	GDI/GDI+	Direct2D
3D	D3D3…D3D10	Direct3D10.1
Text	GDI/GDI+	DirectWrite
Device Management	GDI	DXGI 1.1 & GDI
Imaging	GDI/GDI+/WIC 1.0	Updated WIC

We previewed these technologies at PDC in November 2008. You can see the presentations here:

· Overview of DirectX APIs

· Direct3D

· Direct2D and DirectWrite

We hope to communicate with all of you who are developing software to run on Windows and need performant graphics whether it is text, 2D, 3D or images and whether it runs on the CPU or the GPU using this blog. Here you will be able to interact with the engineers building the graphics subsystem in Windows and the APIs that expose its capabilities. So, welcome to the DirectX blog once again!