DirectX Developer Blog

Introducing the DirectCompute Lecture Series!

Kam VedBrat — Wed, 16 Jun 2010 01:17:00 GMT

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

maryluo — Wed, 06 Jan 2010 21:17:00 GMT

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

Mark Lawrence1 — Fri, 18 Dec 2009 02:04:00 GMT

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

Aisha Ayoub — Sat, 12 Dec 2009 02:14:00 GMT

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!

Aisha Ayoub — Wed, 25 Nov 2009 20:00:00 GMT

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!

Aisha Ayoub — Wed, 18 Nov 2009 15:00:00 GMT

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

Tom_Mulcahy — Tue, 17 Nov 2009 14:50:00 GMT

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

Varun Bhartia — Fri, 13 Nov 2009 00:22:00 GMT

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

Mark Lawrence1 — Fri, 30 Oct 2009 21:02:00 GMT

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!

moneppo — Tue, 27 Oct 2009 22:57:00 GMT

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.