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.
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!
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.
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
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.
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.
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.
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 .gif "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
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
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.
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 renderingThere 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 APIsThere 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 renderingA 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:
- Create an IWICBitmap,
- Pass the bitmap to CreateWicBitmapRenderTarget(),
- BeginDraw(),
- 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.
- Draw to the render target,
- EndDraw(),
- Set up an IWICStream that either writes to a file (InitializeFromFilename) or writes inside the memory (InitializeFromMemory),
- 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.
ConclusionAs 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.
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!
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.
The latest alpha build of Paint.NET v3.5 is using DirectWrite instead of GDI for the Text tool if you are running Windows 7. More details and a pointer to download Paint.NET v3.5 that uses DirectWrite is available here.
Paint.NET is a graphics editing program for Windows, developed on the .NET Framework. Originally created as a Washington State University student project, Paint.NET has evolved into a powerful graphics editor with support for layers, blending, transparency, and plugins.
For applications developed using the .NET framework, there is now a way to leverage the Windows 7 DirectX APIs (Direct3D10, Direct2D, DirectWrite, WIC and Direct3D 11) from your managed applications. The Windows API Code Pack is now available on MSDN. Using Windows API Code Pack you can now incorporate the power of DirectX into your applications without having to write managed-native interop code yourself.
The Windows® API Code Pack for Microsoft® .NET Framework provides a source code library that can be used to access some new Windows 7 features (and some existing features of older versions of Windows operating system) from managed code. It also includes sample applications and API reference documents. You can build the included solution files to get the assemblies for use in your applications (pursuant to the attached license). More information about the Windows API Code Pack is here.
