Clicky

7 on 7: Direct2D and DirectWrite - Jim O'Neil - Technology Evangelist - Site Home - MSDN Blogs

7 on 7: Direct2D and DirectWrite

Jim O'Neil

Technology Evangelist

E-mail  Twitter  LinkedIn  RSS Feed  About me

Check out my new blog at http:>//codocent.com

7 on 7: Direct2D and DirectWrite

  • Comments 2

Windows 7I’m a technical introvert; I love dealing with data, services, interoperability… the plumbing.  So I have to admit, the new graphics stack that Windows 7 introduces – with Direct3D 11, Direct2D, and DirectWrite – didn’t resonate that much with me.  Sure I can appreciate the cool spinny demos as much at the other guy, but I was looking for more… well I found it!

There’s certainly no way to cover in one blog post what is likely a topic for many books in the future, but I wanted to provide the insight I’ve gained into why Direct2D and DirectWrite exist and why they are important to understand.  Let’s start with the obligatory eye-chart showing the changes in Windows 7, and go from there.

 Windows 7 Graphics Stack

One of the first things to note is that the realm of Win32 (and ergo Windows Forms) is out there on the right, not much happening in that world.  And the reason is really rather simple, it’s technology rooted in the last millennium when 16-bit was the rage and GPUs weren’t installed de facto on your machine.  GDI did give way to GDI+ which was an attempt to modernize capabilities, like provide a transparency channel, but since it was still predicated on the original foundation (along with its fundamental limitations), there was only so much that could be improved.

Meanwhile, DirectX was out there on its own track, the stuff for game developers and high-performance graphics.  DirectX was built, more or less, from the ground up to support graphics cards, to handle software vs. hardware rendering, and so on.  Since GDI/GDI+ was about as mature as it could be, DirectX offered a way forward.  We’ve already seen DirectX go mainstream as the underlying graphics engine for WPF and Silverlight, and it’s clear the level of user experience it provides eclipses the prototypical ‘battleship-grey’ interfaces of the past.

So rather than continue the square-peg/round-hole battle with GDI/GDI+, why not build a new graphics subsystem leveraging the investment in DirectX?  And that’s where Direct2D and DirectWrite come in.  Let’s start from the bottom (right above the Kernel) and work up to the new Windows 7 features.

DirectX Graphics Infrastructure (DXGI) resulted from a refactoring of the DirectX runtime to provide better insulation from lower level details.  This allows the graphics components that sit above it to evolve more quickly and provides a framework to plug in new components.  The first ‘new’ component here is Direct3D 10, which was actually introduced in Windows Vista.

Direct3D 10 (or 10.1 as the most recent version is labeled) adds a number of new capabilities that hopefully the graphically-inclined among you can appreciate!  This ships with D3D10Level9, which is sort of a thunking layer that allows Direct3D 10 applications to work on Direct3D 9 hardware.

Direct3D 11, announced at Gamefest 2008, updates the graphics processing pipeline introducing more capabilities including tessellation.  Direct3D 11 also adds the capability to perform general purpose GPU processing (i.e., use the GPU as an extra CPU).

You can think of Direct2D as the successor of GDI/GDI+ for developers that want to bring the next generation of user experiences to their applications.  It’s built on the foundation of Direct3D and in Windows 7 provides efficient interoperability with the older APIs: you can write Direct2D content to a GDI device context, and you can use GDI right on a Direct2D render surface.

DirectWrite brings the enhanced “Direct2D experience” to text. It provides a device-independent layout system for text, to bring the on-screen reading experience closer to the print experience.  It leverages advancements in OpenType (an extension of TrueType) lending capabilities to native and WinForm developers that were previously not available.

Instead of digging into the APIs here (something better left to MSDN documentation in any case), let’s take a look at two scenarios involving Direct2D and DirectWrite to get a handle on how these technologies improve the user experience.

DirectWrite

If you compare text in a GDI (WinForms) application to that of a WPF application, you’ll probably notice some differences.  Both UI technologies do take advantage of ClearType, but GDI is essentially a generation behind in terms of what features it supports.  Most notably, WPF supports both sub-pixel positioning and y-axis anti-aliasing.

Sub-pixel positioning leverages the fact that each pixel is actually made up of three sub-pixels: red, green and blue.  By lighting up only one or two of the subpixels, a more precise ‘edge’ on the glyph boundary can be achieved.  Of course, if you’re turning off a color in the pixel, you introduce color fringes, and edges may appear more greenish, bluish, or reddish.  Depending on the individual’s color sensitivity, DPI settings, etc., this may or may not be an important issue.

y-axis anti-aliasing is best shown in a picture.  On the left, there is jaggedness near the top and bottom curves of the ‘e’, but on the right the image is crisp.   

GDI   DirectWrite


The left was generated via GDI and the right was generated using DirectWrite (and both are using ClearType).  That’s DirectWrite on the right, not WPF, meaning of course, that DirectWrite is now a mechanism that native developers and Windows Forms developers can engage to unlock the newer capabilities of ClearType.  It also unlocks other capabilities such as adornments, that GDI doesn’t render.  Below for instance is a sample of the new Gabriola font rendered in GDI on the left and DirectWrite on the right.

GDI with Gabriola   DirectWrite with Gabriola

Direct2D

For the recent Windows 7 launch event, my colleague Bob Familiar presented on the Direct2D and DirectWrite topic and demonstrated an application that brings to light the differences in the various rendering options.  

The application allows you to render a number of different graphical elements (bitmaps, lines, rectangles) and change the rendering method to demonstrate the differences in the technologies.  Below, you see the application rendering a Bezier curve.

Direct2D example

By changing the API and observing the frames-per-second (fps) as well as the rendering experience, you can get a better appreciation for the various tradeoffs.  The application also enables turning on-and-off anti-aliasing, which provides another dimension of performance versus appearance.

I’ve captured some statistics below based on my own rudimentary tests.  Focus on the relative values of the numbers; they varied quite a bit as I was executing the sample, and these were more-or-less eyeballed.

 

API fps fps
(Anti-aliased)
Comments
GDI 120 120 anti-aliasing not supported in GDI
GDI+ 32 26 definitely a penalty for enhanced capabilities!
D2D HW 415 160 anti-aliasing is expensive but still more responsive than GDI
D2D SW 70 50-130 FPS variance was pretty large (dependency on how much anti-aliasing needed on given frame)?
D2D DXGI 420 170 close to the D2D HW results but integration point is one level lower in the graphics stack
D2D WARP 65 25 on par with D2D SW, but relative disparity with anti-aliasing result is interesting

The last entry here, D2D WARP, refers to the Windows Advanced Rasterization Platform, which provides software rasterization capabilities and enables additional scenarios when graphics hardware is not available.  In my case, I would have expected results similar to Direct2D software rendering.

The Future

Admittedly, I’m scratching the surface here regarding the strengths and weaknesses of each approach, but the key point to take away is that Direct2D is the future of 2-dimensional rendering on Windows. 

Will GDI/GDI+ go away?  Certainly not in the near future, there’s far too many applications relying on it.  That said, there is a migration path here (you can intermingle GDI and Direct2D, for instance) and you should start equipping yourself to set out on that path.

But what if you’re using WPF now, you’re already tapping in to the DirectX pipeline, so is Direct2D relevant to you?  Well, as in all questions like this, the answer is ‘it depends.’ 

Direct2D (like GDI) is an immediate mode API, meaning you tell it everything required to render a portion of the screen.  WPF has retained-mode semantics; it stores the scene in the background and allows the application to directly interact with the graphical elements on it.  That makes for easier development, but less control.  In much the same way that Windows Forms programmers get closer to the metal by passing hWnds to API calls, WPF programmers have Direct2D to provide the additional control or performance, should they need it.

More Reading

Introducing Direct2D (MSDN Magazine – June 2009)

Introducing the Microsoft Direct2D API (Tom Olsen’s blog)

Comparing Direct2D and GDI (DirectX Developer Blog)

Direct2D on MSDN

DirectWrite on MSDN

Join the Conversation
Leave a Comment
  • Please add 8 and 1 and type the answer here:
  • Post
Read What Other's Think
  • Really nice!  Is the application demonstrating this available somewhere?

    I'm working on a graphics layer and would like to do some frame rate comparisons.

    Thanks!

    Keith A

  • oooh, the WARP within D2D application sounds cool  regardless the anti-aliasing result ~

    Could U give more details, thx ☺

Page 1 of 1 (2 items)