Category Archives: Uncategorized

Embracing the Windows Composition Engine

My second article about DirectComposition is now available in MSDN Magazine:

Embracing the Windows Composition Engine

The Windows composition engine represents a departure from a world in which each DirectX app requires its own swap chain to one where even so fundamental a construct is unnecessary. Sure, you can continue to write Direct3D and Direct2D apps using a swap chain for presentation, but you no longer have to. The composition engine brings us that much closer to the metal—the GPU—by allowing apps to create composition surfaces directly.

If you’d like to learn more then be sure to check out my latest course, DirectComposition in Action, where I provide a practical tour of the DirectComposition API.

High-Performance Window Layering Using the Windows Composition Engine

My first article about DirectComposition is now available online in MSDN Magazine:

High-Performance Window Layering Using the Windows Composition Engine

If you like layered windows then this is going to blow your mind. The Windows composition engine is seriously cool and completely changes the way application windows are rendered on the desktop. If you’d like to learn more then be sure to check out my latest course, DirectComposition in Action, where I provide a practical tour of the DirectComposition API.

The Desktop Window Manager

I wrote a lot about the Desktop Window Manager (DWM) back when it first debuted in the Windows Vista beta releases. You can read those articles here and here. This dates back to 2006. At that time all we had was the rather limited DWM API. While it was interesting and neat to be able to extend a window’s glassy frame and apply the blur to the client area, it was also clear that the operating system was holding back on us. The DWM was capable of a lot more. Fast forward to Windows 8 and the operating system finally allows us to use the awesome power of the DWM inside our own applications. DWM is the name of the Windows composition engine and my new course tells the story of the new API that lets you tap into its power:

DirectComposition in Action

Learn how to use DirectComposition to easily produce high-performance visual effects with the Windows composition engine.

dwm

DirectComposition in Action

My latest Pluralsight course is now available online:

DirectComposition in Action

Learn how to use DirectComposition to easily produce high-performance visual effects with the Windows composition engine.

DirectComposition is the primary API for the Windows composition engine. Have you ever wondered what the DWM process is up to? Did you wish you could tap into some of its power? Then this course is for you. The DirectComposition API enables you to build the highest-performance native graphics applications using a “retained mode” graphics API. The composition engine retains a visual tree of bitmaps that may be rendered with “immediate mode” graphics APIs such as Direct2D or Direct3D. You get the best of both worlds and can achieve visual effects at a performance level that was never possible prior to the introduction of the DirectComposition API. This course will give you a practical tour of the API by showing you how to build a DirectX-based card game from scratch, producing animated transitions for a visually engaging user interface.

Go and watch it now!

Here’s a preview of what you can expect. This is a little game I wrote for the kids that illustrates some of the power of DirectComposition and the Windows composition engine.

The Essentials of the Windows Runtime – Coming Soon

The sequel to my COM courses is on its way. I’ve finally started work on “The Essentials of the Windows Runtime” for Pluralsight. This is a deep dive into the technology behind the new wave of platform APIs that define the Windows 8.1 and Windows Phone 8.1 environments. Other courses at Pluralsight will teach you how to build apps for these environments. This course will teach you how and why they work under the hood.

The Essentials of the Windows Runtime is a behind-the-scenes look at WinRT, from its deep roots in COM, the influence of .NET, the Windows security model, asynchronous I/O, distribution, metadata, and much more. As I did with my course, The Essentials of COM, I’m going to start from the ground up and show you how it all comes together with C++. Once the mechanics are understood, I’ll show you how you can use both WRL and C++/CX to simplify different scenarios including component development, app development, using WinRT from the desktop, and of course Windows Phone will also be covered.

I won’t spend too much time on the WinRT libraries since those are easily grasped and covered in many other places but I will cover some of the foundational libraries including the core window model, graphics, containers, streams, security, and a few other interesting topics. There’s an interesting story to tell here and some great technology to discover. I hope you’ll join me in exploring the Window Runtime.

DirectComposition in Action – Coming Soon

Update: Go and watch the course now!

I’ve been spending a lot of time with DirectComposition lately. DirectComposition is the primary API for the Windows composition engine. DirectComposition in Action is the name of my next Pluralsight course. I’ve also written a series of articles on DirectComposition for MSDN Magazine. The first is scheduled for the June 2014 issue. Here’s a preview of what you can expect. This is a little game I wrote for the kids that illustrates some of the power of DirectComposition and the Windows composition engine.

SQLite with C++

My latest article for Visual Studio Magazine is now online. This concludes the SQLite miniseries. I hope you’ve enjoyed it and do let me know if you’d like to learn more. SQLite is a fantastic little database engine. Here are links to all three articles.

1. Using SQLite with Modern C++

2. SQLite Performance and Prepared Statements

3. SQLite Queries and Primary Keys

I also covered SQLite in 10 Practical Techniques to Power Your Visual C++ Apps and I may do a course devoted to SQLite in the future.

Making a Window DPI-Aware

How do you make a desktop window DPI-aware? Last time I showed you a few approaches to creating a top-level window on the desktop. If you care at all about the appearance of your app then one of the first things you ought to do is make the window DPI-aware. I covered this at length in an article for MSDN Magazine. Here I want to just summarize the most essential ingredients. The first thing to do is tell Windows that your app is per-monitor DPI-aware. The best way is to use a manifest and you can get the scoop on that from my article in MSDN Magazine. Here I’m interested in the code. I’m going to start with the Window class template that I introduced last time as well as the SampleWindow class that derived from it.

The earliest reasonable opportunity to determine the effective DPI for a given window is in its WM_CREATE handler. Once created the window must also respond to the WM_DPICHANGED message so that it can be notified of any changes to the DPI values over time. Here’s an update to the SampleWindow’s MessageHandler to intercept both of these additional messages.

LRESULT MessageHandler(UINT message,
                       WPARAM const wparam,
                       LPARAM const lparam)
{
    if (WM_PAINT == message)
    {
        PaintHandler();
    }
    else if (WM_DPICHANGED == message)
    {
        DpiHandler(wparam);
    }
    else if (WM_CREATE == message)
    {
        CreateHandler();
    }
    else
    {
        return __super::MessageHandler(message,
                                       wparam,
                                       lparam);
    }

    return 0;
}

The original version only responded to the WM_PAINT message. The WM_DPICHANGED message handler receives the new DPI values through its WPARAM while the WM_CREATE does not require any additional information at this point. Let’s start with the CreateHandler method. The first thing it needs to do is determine the monitor nearest the window. Even though the WM_CREATE message is received before the window is visible on the desktop, the window already has its position and size so this is a fine time to call the MonitorFromWindow function to retrieve the monitor that has the largest intersection with my window. Given the window handle, I can call the GetDpiForMonitor function to retrieve the monitor-specific DPI values.

float m_dpiX = 0.0f;
float m_dpiY = 0.0f;

void CreateHandler()
{
    HMONITOR const monitor = MonitorFromWindow(m_window,
                                               MONITOR_DEFAULTTONEAREST);

    unsigned x = 0;
    unsigned y = 0;

    HR(GetDpiForMonitor(monitor,
                        MDT_EFFECTIVE_DPI,
                        &x,
                        &y));

    m_dpiX = static_cast<float>(x);
    m_dpiY = static_cast<float>(y);
}

I’m just using two member variables to keep track of the DPI values for the window and I’m storing the DPI values using floating point since most DPI-aware rendering uses floating point coordinates. So the window begins life with an awareness of the DPI values it ought to use for scaling and rendering but it’s also responsible for keeping those values up to date. That’s the job of the DpiHandler method. It simply extracts the updated DPI values from the message’s WPARAM and updates the same member variables.

void DpiHandler(WPARAM const wparam)
{
    m_dpiX = LOWORD(wparam);
    m_dpiY = HIWORD(wparam);
}

This WM_DPICHANGED handler could technically do the exact same thing as the WM_CREATE handler and look up the monitor and DPI values directly but this is certainly more convenient. And that’s all there is to it. Assuming you’ve configured your manifest correctly you window will always have the correct DPI values to rely on. Until next time…

For more practical advice and examples for writing apps with Visual C++ please check out 10 Practical Techniques to Power Your Visual C++ Apps.

Read the previous installment in this series: Classy Windows