Windows Development with C + +: rendering of Windows runtime

The Windows Runtime (WinRT) application Model (msdn.microsoft.com/magazine/dn342867) is discussed in my previous column. I demonstrated how to write a Windows store or a Windows Phone application using standard C + + and classic COM, with only a few WinRT API functions. There is no doubt that you do not have to use language projection such as C++/CX or C #. Being able to circumvent these abstractions is a powerful feature and a great way to understand how this technology works.

I introduced DIRECT2D 1.1 in my May 2013 column and demonstrated how to use it to render in a desktop application (msdn.microsoft.com/magazine/dn198239). The next column describes the Dx.h library provided on dx.codeplex.com, which can greatly simplify DirectX programming (msdn.microsoft.com/magazine/dn201741) in C + +.

The code in the last column is sufficient for implementing an Corewindow application, but does not provide any rendering.

This month, I'll show you how to take advantage of this basic framework and add rendering support. The WinRT application model is optimized for using DirectX rendering. I'll show you how to take advantage of what you've learned in previous columns about DIRECT2D and Direct3D rendering, applying it to Corewindow based WinRT applications, specifically, Dx.h 1.1 through the DIRECT2D library. In most cases, the actual direct2d and Direct3D drawing commands you need to write are the same regardless of whether your goal is desktop or Windows running. However, there are some subtle differences, of course, that make it fully operational from the very beginning there is a big difference. So I'm going to go ahead and show you how to display some pixels on the screen!

In order to support rendering correctly, Windows must be aware of specific events. At a minimum, this includes changes to the visibility and size of the window, as well as to the logical display of the DPI configuration for the user's selection. In the activated event that was described in the last column, these new events are reported to the application through COM interface callbacks. The Icorewindow interface provides a way to register the visibilitychanged and sizechanged events, but first I need to implement the corresponding handlers. The two COM interfaces I need to implement are very similar to the class templates generated by the activated event handler and its Microsoft Interface Definition language (MIDL):

typedef Itypedeventhandler<corewindow *, Visibilitychangedeventargs *>
Ivisibilitychangedeventhandler;
typedef Itypedeventhandler<corewindow *, Windowsizechangedeventargs *>
Iwindowsizechangedeventhandler;

The COM interface that must be implemented next is called Idisplaypropertieseventhandler, thank goodness this interface has been defined. All I need to do is include the relevant header files in it:

#include <Windows.Graphics.Display.h>

In addition, the related types are defined in the following namespaces:

Using namespace Abi::windows::graphics::D isplay;

Based on these definitions, I can update the Samplewindow class described in my last column and inherit from these three interfaces:

struct Samplewindow:
...
Ivisibilitychangedeventhandler,
Iwindowsizechangedeventhandler,
Idisplaypropertieseventhandler

It is also necessary to remember to update my QueryInterface implementation to indicate support for these interfaces. This content will allow you to do it yourself. Of course, as I said last time, Windows runtime does not care where to implement these COM interface callbacks. It follows the principle that Windows runtime does not assume that my application Iframeworkview (the primary interface implemented by the Samplewindow Class) also implements these callback interfaces. Therefore, although QueryInterface does correctly handle queries for these interfaces, Windows runtime does not query them. Instead, I need to register the corresponding event, and the best location is in the Iframeworkview Load method implementation. To remind you, the Load method is a way to paste all the code here so that you can prepare the application for initial rendering. Next, register the visibilitychanged and sizechanged events in the Load method:

Eventregistrationtoken token;
HR (M_window->add_visibilitychanged (this, &token));
HR (M_window->add_sizechanged (this, &token));

This will tell Windows exactly where to look for the first two interface implementations. The third and final interface is for the Logicaldpichanged event, but this event registration is provided by the Idisplaypropertiesstatics interface. This static interface is implemented by the WinRT DisplayProperties class. I just use the Getactivationfactory function template to get it (in my recent column I can find the getactivationfactory implementation):

Comptr<idisplaypropertiesstatics> m_displayproperties;
M_displayproperties = getactivationfactory<idisplaypropertiesstatics> (
Runtimeclass_windows_graphics_display_displayproperties);

The member variable retains this interface pointer, and in the life cycle of the window, I need to invoke it at different points. Now, I can register the logicaldpichanged event in the Load method:

HR (m_displayproperties->add_logicaldpichanged (this, &token));

The implementation of these three interfaces will be returned later. Now is the time to prepare the DirectX infrastructure. I will need standard device resource processing assemblies, which have been discussed several times in previous columns:

void Createdeviceindependentresources () {}
void Createdevicesizeresources () {}
void Createdeviceresources () {}
void Releasedeviceresources () {}