DirectX Developer Blog

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-29T07: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. One exception to this is bitmaps created with the CreateBitmapFromDxSurface API which are resident in video memory. 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.