Read the official announcement.

Download the specification.

A while ago I wrote an article about how to use the Microsoft Parallel Patterns Library (PPL) to render the Mandelbrot fractal using multiple CPU cores. That article can be found here.

This new article will make the Mandelbrot renderer multiple times faster by using a new Microsoft technology called C++ AMP: Accelerated Massive Parallelism, introduced in the Visual C++ 11 Preview.

The code in the previous article showed each line of the fractal immediately after it was calculated. For this article, this is changed. The Mandelbrot image will be rendered completely off-screen, and only shown when the entire image has been calculated. This is to reduce overhead of displaying the fractal line-by-line, especially with the C++ AMP version which will be so fast that this overhead could become pretty substantial.

I will also switch to single precision floating point numbers, because the GPU and GPU driver combination on my Windows 7 machine does not support double precision floating point numbers. The C++ AMP technology itself supports both single- and double precision floating point arithmetic. However, whether or not double precision arithmetic works depends on your specific GPU hardware and your specific drivers from your GPU vendor. A side effect of using single precision arithmetic in the Mandelbrot renderer is that the image will get blocky at big zoom levels. At the end of this article, a piece of code is shown how to check if an accelerator in your system supports double precision arithmetic or not. You could use that to decide at runtime whether to use a single precision or double precision implementation. This is left as an exercise for the reader.

Single-Threaded Implementation

All implementations, the single-threaded, the PPL, and the C++ AMP Mandelbrot version, use the following setup:

const int halfHeight = int(floor(m_nBuffHeight/2.0));
const int halfWidth = int(floor(m_nBuffWidth/2.0));
const int maxiter = 1024;
const float escapeValue = 4.0f;
float zoomLevel = float(m_zoomLevel);
float view_i = float(m_view_i);
float view_r = float(m_view_r);
float invLogOf2 = 1 / log(2.0f);
if (m_buffers[m_nRenderToBufferIndex].empty())
    return;
unsigned __int32* pBuffer = &(m_buffers[m_nRenderToBufferIndex][0]);

Here is the single-threaded implementation from my previous article, but updated to use single precision floating point arithmetic, and to render one Mandelbrot image to the buffer before displaying it:

for (int y = -halfHeight; y < halfHeight; ++y)
{
    // Formula: zi = z^2 + z0
    float Z0_i = view_i + y * zoomLevel;
    for (int x = -halfWidth; x < halfWidth; ++x)
    {
        float Z0_r = view_r + x * zoomLevel;
        float Z_r = Z0_r;
        float Z_i = Z0_i;
        float res = 0.0f;
        for (int iter = 0; iter < maxiter; ++iter)
        {
            float Z_rSquared = Z_r * Z_r;
            float Z_iSquared = Z_i * Z_i;
            if (Z_rSquared + Z_iSquared > escapeValue)
            {
                // We escaped
                res = iter + 1 - log(log(sqrt(Z_rSquared + Z_iSquared))) * invLogOf2;
                break;
            }
            Z_i = 2 * Z_r * Z_i + Z0_i;
            Z_r = Z_rSquared - Z_iSquared + Z0_r;
        }

        unsigned __int32 result = RGB(res * 50, res * 50, res * 50);
        pBuffer[(y + halfHeight) * m_nBuffWidth + (x + halfWidth)] = result;
    }
}

Multi-Threaded Implementation (PPL)

Parallelizing this implementation using the Microsoft Parallel Patterns Library (PPL) is shown in my previous article. Again, this implementation has been updated to use single precision arithmetic and to render one whole frame to the buffer before displaying it. The updated code looks as follows:

parallel_for(-halfHeight, halfHeight, 1, [&](int y)
{
    // Formula: zi = z^2 + z0
    float Z0_i = view_i + y * zoomLevel;
    for (int x = -halfWidth; x < halfWidth; ++x)
    {
        float Z0_r = view_r + x * zoomLevel;
        float Z_r = Z0_r;
        float Z_i = Z0_i;
        float res = 0.0f;
        for (int iter = 0; iter < maxiter; ++iter)
        {
            float Z_rSquared = Z_r * Z_r;
            float Z_iSquared = Z_i * Z_i;
            if (Z_rSquared + Z_iSquared > escapeValue)
            {
                // We escaped
                res = iter + 1 - log(log(sqrt(Z_rSquared + Z_iSquared))) * invLogOf2;
                break;
            }
            Z_i = 2 * Z_r * Z_i + Z0_i;
            Z_r = Z_rSquared - Z_iSquared + Z0_r;
        }

        unsigned __int32 result = RGB(res * 50, res * 50, res * 50);
        pBuffer[(y + halfHeight) * m_nBuffWidth + (x + halfWidth)] = result;
    }
});

C++ AMP Implementation

C++ AMP is a new technology being developed by Microsoft for C++ to allow you to easily write code that takes advantage of the computing power of accelerators, such as GPUs. For now, C++ AMP requires DirectX 11 GPUs. C++ AMP abstracts the accelerators for you. When using C++ AMP, you don’t need to worry about what kind of accelerator is in the system. For example, there is no need to write one implementation for an NVidia GPU and another for an AMD GPU. You just write 1 implementation, and C++ AMP handles the rest. If you have multiple GPUs in your system, C++ AMP can use them all at the same time, and they don’t even need to be of the same vendor. For example, if you have a system with both an AMD and an NVidia GPU in it, C++ AMP can use them both together.

Microsoft has the intention to make C++ AMP an open specification, so that other compiler vendors could also add support for it.

For this simple Mandelbrot renderer, once you have a PPL implementation, it’s almost trivial to transform it to C++ AMP. Without further ado, here is the C++ AMP version, with a detailed explanation after the code:

try
{
    array_view<writeonly<unsigned __int32>, 2> a(m_nBuffHeight, m_nBuffWidth, pBuffer);
    parallel_for_each(a.grid, [=](index<2> idx) restrict(direct3d)
    {
        // Formula: zi = z^2 + z0
        int x = idx[1] - halfWidth;
        int y = idx[0] - halfHeight;
        float Z0_i = view_i + y * zoomLevel;
        float Z0_r = view_r + x * zoomLevel;
        float Z_r = Z0_r;
        float Z_i = Z0_i;
        float res = 0.0f;
        for (int iter = 0; iter < maxiter; ++iter)
        {
            float Z_rSquared = Z_r * Z_r;
            float Z_iSquared = Z_i * Z_i;
            if (Z_rSquared + Z_iSquared > escapeValue)
            {
                // We escaped
                res = iter + 1 - fast_log(fast_log(fast_sqrt(Z_rSquared + Z_iSquared))) * invLogOf2;
                break;
            }
            Z_i = 2 * Z_r * Z_i + Z0_i;
            Z_r = Z_rSquared - Z_iSquared + Z0_r;
        }

        unsigned __int32 result = RGB(res * 50, res * 50, res * 50);
        a[idx] = result;
    });
    a.synchronize();
}
catch (const Concurrency::runtime_exception& ex)
{
    MessageBoxA(NULL, ex.what(), "Error", MB_ICONERROR);
}

Everything of C++ AMP is in the concurrency namespace. Certain Direct3D interoperability functionality, such as fast_log(), is in the concurrency::direct3d namespace.

The first thing the C++ AMP implementation does is defining a 2D array_view over the buffer. The array_view class creates a multi-dimensional view over a user supplied buffer. The data of this buffer is copied to and from GPU memory on demand by C++ AMP. The basic use of array_view is:

array_view<type, dim>

where type is the type of data in the buffer and dim is the dimensionality of your data. The dimensionality can be anything you want; it can be 1D, 2D, 3D, 4D… When you define your array_view like this, it will be a read and write view over your buffer, which means that initial data is copied from system memory to GPU memory, and the end result is copied from GPU memory back to system memory. If your GPU kernel is only writing to the buffer, the array_view can be defined as a write-only view over your buffer as follows:

array_view<writeonly<type>, dim>

This will optimize memory transfers. No initial data is copied from system memory to the GPU memory; data is only copied after finishing the calculations, from GPU memory to system memory.
The opposite is also possible. You can create a read-only array_view as follows:

array_view<const type, dim>

This will only copy initial data from system memory to GPU memory, and will not copy it back from GPU memory to system memory.

The above Mandelbrot implementation only writes to the buffer, so the array_view is defined as write-only.

Another option is to use the array class instead of array_view. The array class allocates a buffer, while array_view creates a view over a user allocated buffer.

After the C++ AMP Mandelbrot implementation has created the array_view, it uses concurrency::parallel_for_each().

The first parameter to the parallel_for_each() is a compute domain, called a grid. If you have an array_view, you can simply use its grid property as shown in the above implementation. For this Mandelbrot renderer, we have a two dimensional array_view, so the grid will also be 2D. On each position of the grid, a computation will be performed.

The second parameter to parallel_for_each() is a lambda expression that specifies restrict(direct3d) to say that the code in the lambda expression should be executed on your GPU, instead of your CPU. The restrict(direct3d) attribute is a compile time check; the compiler will check the code to see whether the code will be able to run on GPUs. For example, if you call a system call in your restrict(direct3d) GPU kernel, the code will not work on the GPU, and compilation will fail. In other words, if you use restrict(direct3d) and it compiles without errors, you are not violating any GPU restrictions and the code is valid to be executed on GPUs. Any function that you call from inside a GPU kernel should also have the restrict(direct3d) specifier. There are a number of restrictions on the code in a restrict(direct3d) function. MSDN lists them as follows:

• The function can call only functions that have the restrict(direct3d) clause.
• The function must be inlinable.
• The function can declare only int, unsigned int, float, and double variables, and classes and structures that contain only these types.
• Lambda functions cannot capture by reference and cannot capture pointers.
• References and single-indirection pointers are supported only as local variables and function arguments.
• The following are not allowed:
  • Recursion.
  • Variables declared with the volatile keyword.
  • Virtual functions.
  • Pointers to functions.
  • Pointers to member functions.
  • Pointers in structures.
  • Pointers to pointers.
  • goto statements.
  • Labeled statements.
  • try, catch, or throw statements.
  • Global variables.
  • Static variables. Use tile_static Keyword instead.
  • dynamic_cast casts.
  • The typeid operator.
  • asm declarations.
  • Varargs.

The lambda expression accepts only one parameter. This parameter is an index into the compute domain (= grid). For the 2D Mandelbrot case, this index is a 2D index denoted as:

index<2> idx

You can access each dimensionality of this index using array notation, for this 2D index you can use idx[0] and idx[1]. This gives you the position in the grid. An added bonus of using an index is that the code looks cleaner. In the C++ AMP version of the Mandelbrot renderer there is no ugly buffer index calculation. Compare the C++ AMP version:

a[idx] = result;

with the PPL version and single-threaded version:

pBuffer[(y + halfHeight) * m_nBuffWidth + (x + halfWidth)] = result;

The lambda expression should capture all variables it needs by value, except concurrency::array objects, which have to be captured by reference. MSDN also states that the following restrictions apply on the object types that can be captured:

• No pointers or references (exception: array)
• No char, short, or long long types
• No bool types
• Structs or classes that contain supported types are allowed
• No objects that contain virtual functions or virtual bases
• Structs or classes must be PODs (more formally, they must be copyable by blitting)

parallel_for_each() will throw exceptions in case of errors. Possible reasons are:

• Failure to create the shader, which is the code that runs on the accelerator
• Failure to create buffers
• Invalid grid passed
• Mismatched accelerators

The body of the lambda expression supplied to the parallel_for_each() (= kernel) runs asynchronously with the CPU code following the parallel_for_each() call, which means that your CPU code after the parallel_for_each() call continues to execute in parallel with the code inside the body of the parallel_for_each() lambda, until a synchronization point is reached. If your CPU code at a certain point observes the result of the parallel_for_each() kernel, by inspecting the array_view in this example, at that point C++ AMP synchronizes and blocks until the GPU kernel is finished. A synchronize is also forced when the array_view object goes out of scope. However, when the array_view goes out of scope, the synchronize() method is called from within the array_view destructor and thus is not allowed to throw any exceptions. In that case, GPU and CPU exceptions that happen during the synchronization, including during transferring results from GPU memory back to system memory, will be lost. For this reason, it is recommended to manually call synchronize() at a suitable point in time, and properly catch any exceptions.

C++ AMP also includes a function called copy_async() which copies data from a source to a destination. The function returns a C++11 std::future which you can check whenever you want to see whether the copy has finished or not.

To get even more performance out of your accelerators, you can investigate the tiled model, which works up to three dimensions. However, this article will not go deeper in on this more advanced feature. You can find an example in this blog post: tile_static, tile_barrier, and tiled matrix multiplication with C++ AMP.

You can use the accelerator and accelerator_view classes to retrieve information from installed accelerators in a system; and use the get_accelerators() function to get a vector of accelerators. This introductory article on C++ AMP does not go deeper in on the functionality of these classes. Only a small example is given.

You can get a hold of the default accelerator in a system by using the default constructor of the accelerator class. Once you have this, you can query it for information using the supports() method and the accelerator_restriction enumeration. For example, the following code checks whether the default accelerator supports double precision calculations or not:

accelerator acc;
if (acc.supports(accelerator_restriction::double_precision))
    cout << "Your C++ AMP default GPU supports double precision arithmetic." << endl;
else
    cout << "Your C++ AMP default GPU does not support double precision arithmetic." << endl;

Results

On my test machine (Intel Core i7-2600k, 16GB RAM, AMD Radeon HD 6800) I get the following averages in milliseconds for rendering one frame at the default zoom level at a resolution of 1916×951:

• Single threaded version: 1167 ms
• PPL version: 194 ms
• C++ AMP version: 31 ms

The Intel Core i7-2600k has 4 physical cores. With hyperthreading enabled, this results in 8 cores seen by the operating system. When using the single threaded version, there is only 1 of these cores being utilized. Using the PPL version, all 8 cores are fully loaded. The C++ AMP version uses almost no CPU power at all; it only uses the GPU cores. On my Radeon HD 6800, it executes around 220 threads.

When you are running Windows 8 Preview with Visual C++ 11 Preview, you can use GPU debugging and put breakpoints in your GPU code; see Debugging a C++ AMP Application. At the moment, GPU debugging does not work on Windows 7.

Sample Application

This article comes with a sample application. You need the Visual Studio 11 Developer Preview to compile it. Unfortunately, I am not able to include a pre-compiled binary because that binary would depend on the Visual C++ 11 Preview redistributable which is not yet available.

The sample application has a toolbar with the following ‘programmers-art’ buttons:

• R: Render one frame using the selected method
• -: Zoom out on the Mandelbrot fractal
• +: Zoom in on the Mandelbrot fractal
• S: Select the single-threaded implementation
• PPL: Select the PPL implementation
• AMP: Select the C++ AMP implementation
• B: Benchmark: Render a number of frames and display the average in the window title bar.

After rendering a frame, the title bar shows how long it took to render and at what resolution. You can use the left mouse button to move around in the Mandelbrot fractal, and the mouse wheel to zoom in and out. Note however that this interactive moving and zooming is only useful with the C++ AMP implementation, because the single-threaded and PPL versions are too slow for interactivity.

Conclusion

This article is an introduction to, and demonstration of the power of C++ AMP. Check out the official documentation at C++ AMP: Accelerated Massive Parallelism for more information. Also check out Daniel Moth’s blog, containing a wealth of information on C++ AMP.

Disclaimer: Keep in mind that this article is written using the Developer Preview of Visual C++ 11. Certain aspects might change in the final version of Visual C++ 11.

Resources

• Daniel Moth’s blog (PM of C++ AMP): this blog contains a wealth of information on C++ AMP.
• MSDN Native parallelism blog (team blog)
• MSDN Dev Center for Parallel Computing
• MSDN Forums to ask questions

Downloads

• Sample application

Already joining us:

• Tarek Madkour from Microsoft, Principal Program Manager Lead in the Visual C++ team
• Jim Hogg from Microsoft, his main focus is C++ compiler optimizations

If you ever wanted to speak directly with the Microsoft Visual C++ development team, now is your chance.
If you know any C++ people that would be interested in this, please tell them about it.

Since I need to make reservations somewhere, please let me know (marc.gregoire@nuonsoft.com) before 31st of January if you are joining us for dinner.

If you have any questions, don’t hesitate to ask me.

PS: this is not a sponsored dinner, so everyone should pay for themselves, but that shouldn’t be a problem I hope.

The official page gives the following description of the MEET program:

Do you have a complex problem, but not the knowledge to solve it? Then you can get in contact with a community of Belgian experts.
All MEET members are selected for their knowledge and skills in their field. And they are also excellent communicators. All share knowledge through their personal blogs and they are also frequent speakers at Microsoft events or their respective user group.
MEET gets the explicit support of Microsoft Belgium and Luxembourg.

HWND GetDesktopHWND()
{
  HWND hProgman = FindWindow(_T("Progman"), 0);
  if (hProgman)
    return FindWindowEx(hProgman, 0, _T("SHELLDLL_DefView"), 0);

  return NULL;
}

void ToggleDesktopIcons()
{
  HWND hWndDesktop = GetDesktopHWND();
  if (hWndDesktop)
    SendMessage(hWndDesktop, WM_COMMAND, 0x7402, 0);
}

Are you passionate about C++ and interested in finding like-minded people? Feel like coming together, setting an informal User Group in 2012? We’d like to support you in that and have a call to action for you.

Marc Gregoire, C++ MVP and author of the book Professional C++, 2nd Edition is one of the folks passionate about the technology and interested in starting up a more active C++ community in Belgium. Are you interested? Join Marc and the MSDN Belux Team for an informal discussion at the Microsoft office in Zaventem on Tuesday January 10th 2012 at 6:30 PM.

Contact Marc through email, leave a note on the MSDN Belux Team blog or reach out to Katrien De Graeve from MSDN Belux via her Twitter and we’ll see you in January.

If you are looking for some of the other Microsoft technology communities there is the full listing here: http://msdn.microsoft.com/nl-be/cc196311.

.

• Pixel perfect, ready-to-use royalty-free icons
• 48×48, 32×32, 24×24, 16×16
• RGB with alpha channel, RGB
• 96 PPI compatible with WPF, Silverlight, MFC, VB…
• Normal, Hot, Disabled states
• PNG, ICO, BMP file formats
• Many derivatives & overlays
• Lifetime Commercial/No-Attribution License

The set contains 1108 unique icons for €39.

And even better, you get 30% discount if you order before November 20 by following this link.

The Windows Imaging Component (WIC) provides an extensible framework for working with images and image metadata. WIC makes it possible for independent software vendors (ISVs) and independent hardware vendors (IHVs) to develop their own image codecs and get the same platform support as standard image formats (for example, TIFF, JPEG, PNG, GIF, BMP, and HDPhoto). A single, consistent set of interfaces is used for all image processing, regardless of image format, so any application using the WIC gets automatic support for new image formats as soon as the codec is installed. The extensible metadata framework makes it possible for applications to read and write their own proprietary metadata directly to image files, so the metadata never gets lost or separated from the image.

The MSDN states the primary features of WIC as follows:

• Enables application developers to perform image processing operations on any image format through a single, consistent set of common interfaces, without requiring prior knowledge of specific image formats.
• Provides an extensible “plug and play” architecture for image codecs, pixel formats, and metadata, with automatic run-time discovery of new formats.
• Supports reading and writing of arbitrary metadata in image files, with the ability to preserve unrecognized metadata during editing.
• Preserves high bit depth image data, up to 32 bits per channel, throughout the image processing pipeline.
• Provides built-in support for most popular image formats, pixel formats, and metadata schemas.

WIC comes with the following standard built-in codecs:

• BMP (Windows Bitmap Format), BMP Specification v5.
• GIF (Graphics Interchange Format 89a), GIF Specification 89a/89m
• ICO (Icon Format)
• JPEG (Joint Photographic Experts Group), JFIF Specification 1.02
• PNG (Portable Network Graphics), PNG Specification 1.2
• TIFF (Tagged Image File Format), TIFF Specification 6.0
• Windows Media Photo, HD Photo Specification 1.0

All codecs can both load and save the specific image format, except the ICO codec which can only load icon files and not save them.

Reading all this, it looks like WIC is pretty powerful, and the best part is that it’s easy to use as I will demonstrate in this article. So, let’s get started with some code.
The first thing you need to do is include the following headers and link with Windowscodecs.lib:

#include <wincodec.h>
#include <wincodecsdk.h>

WIC uses COM, however, this should not scare you away. The main thing to remember is to use a COM smart pointer which makes it much easier and prevents memory leaks. The COM smart pointer I’ll be using is CComPtr. This smart pointer is defined in atlbase.h.
To start working with WIC, you need an instance of the IWICImagingFactory. You only have to create one such instance and can use it for the entire lifetime of the application. Below is the header file of a class that wraps an IWICImagingFactory instance into a singleton class to give easy access to it from anywhere in your application.

#pragma once

#include <atlbase.h>
#include <wincodec.h>
#include <memory>

class CWICImagingFactory
{
public:
	inline static CWICImagingFactory& GetInstance()
	{
		if (nullptr == m_pInstance.get())
			m_pInstance.reset(new CWICImagingFactory());
		return *m_pInstance;
	}

	virtual IWICImagingFactory* GetFactory() const;

protected:
	CComPtr<IWICImagingFactory> m_pWICImagingFactory;

private:
	CWICImagingFactory();	// Private because singleton
	static std::shared_ptr<CWICImagingFactory> m_pInstance;
};

This code is using the C++11 std::shared_ptr smart pointer. If your compiler does not yet support this smart pointer, you can replace it with any other smart pointer, for example boost::shared_ptr. Note that this singleton class is not threadsafe. The GetInstance() method contains a race-condition. So, if you need this singleton to be threadsafe, you’ll have to add some synchronization to the GetInstance() method.

The implementation file of the CWICImagingFactory is rather straightforward:

#include "stdafx.h"
#include "WICImagingFactory.h"
#include <assert.h>

std::shared_ptr<CWICImagingFactory> CWICImagingFactory::m_pInstance;

CWICImagingFactory::CWICImagingFactory()
	: m_pWICImagingFactory(nullptr)
{
	HRESULT hr = CoCreateInstance(CLSID_WICImagingFactory, NULL, CLSCTX_INPROC_SERVER,
		IID_IWICImagingFactory, (LPVOID*)&m_pWICImagingFactory);
	assert(SUCCEEDED(hr));
}

IWICImagingFactory* CWICImagingFactory::GetFactory()  const
{
	assert(m_pWICImagingFactory);
	return m_pWICImagingFactory;
}

Now that we have access to an IWICImagingFactory instance, let’s start with writing the definition of a class called CNuonImg that uses WIC to load and render images.

#pragma once

#include <atlbase.h>
#include <wincodec.h>
#include <wincodecsdk.h>

class CNuonImg
{
public:
	CNuonImg();
	virtual ~CNuonImg();

	// Opens the nFrame-th frame of the given image file.
	// Throws HRESULT in case of failure.
	virtual void Open(const wchar_t* pszFile, UINT nFrame = 0);

	// Returns true if an image is loaded successfully, false otherwise
	virtual bool IsLoaded() const;

	// Renders the loaded image to the given device context hDC,
	// at position x,y and size cx, cy.
	// Throws HRESULT in case of failure.
	virtual void Render(HDC hDC, UINT x, UINT y, UINT cx, UINT cy);

	// Returns the width of the loaded image.
	virtual UINT GetWidth() const;

	// Returns the height of the loaded image.
	virtual UINT GetHeight() const;

protected:
	virtual void Cleanup();

	CComPtr<IWICBitmapDecoder> m_pDecoder;
	CComPtr<IWICBitmapFrameDecode> m_pFrame;
	CComPtr<IWICFormatConverter> m_pConvertedFrame;
	UINT m_nWidth;
	UINT m_nHeight;
};

The constructor of this class initializes the data members, and initializes COM.

CNuonImg::CNuonImg()
	: m_pDecoder(nullptr)
	, m_pFrame(nullptr)
	, m_pConvertedFrame(nullptr)
	, m_nWidth(0)
	, m_nHeight(0)
{
	// Initialize COM
	CoInitialize(nullptr);
}

The destructor performs some cleanup and uninitializes COM.

CNuonImg::~CNuonImg()
{
	Cleanup();

	// Uninitialize COM
	CoUninitialize();
}

The Cleanup() method cleans up the previously loaded image and prepares the class to load another image.

void CNuonImg::Cleanup()
{
	m_nWidth = m_nHeight = 0;

	if (m_pConvertedFrame)
	{
		m_pConvertedFrame.Release();
		m_pConvertedFrame = nullptr;
	}
	if (m_pFrame)
	{
		m_pFrame.Release();
		m_pFrame = nullptr;
	}
	if (m_pDecoder)
	{
		m_pDecoder.Release();
		m_pDecoder = nullptr;
	}
}

It’s not strictly required to call Cleanup() from the destructor. The class is using CComPtr to wrap all COM pointers, and the CComPtr class will automatically release the COM pointers when the destructor of the CComPtr instances is executed. However, the class needs a Cleanup() method anyway, to allow loading a second image with the same CNuonImg instance, so, we might as well call the Cleanup() method in the destructor also.

The remaining of the code will call a lot of methods on COM interfaces. It’s good coding practice to check the return value of each COM method call. To make this easier, the code uses the following little helper macro:

#define IfFailedThrowHR(expr) {HRESULT hr = (expr); if (FAILED(hr)) throw hr;}

This executes an expression expr, which returns an HRESULT. The HRESULT is checked and if it’s a failure, the HRESULT value is thrown as an exception. You should change this error handling mechanism to suit your requirements.

The Open() method is of course the most interesting method. It loads the given image. The parameter nFrame is the index of the frame that you want to load. Certain image formats, for example TIFF and GIF, support multiple frames inside a single image file. The first frame in the file has index 0.

void CNuonImg::Open(const wchar_t* pszFile, UINT nFrame/* = 0*/)
{
	try
	{
		// Cleanup a previously loaded image
		Cleanup();

		// Get the WIC factory from the singleton wrapper class
		IWICImagingFactory* pFactory = CWICImagingFactory::GetInstance().GetFactory();
		assert(pFactory);
		if (!pFactory)
			throw WINCODEC_ERR_NOTINITIALIZED;

		// Create a decoder for the given image file
		IfFailedThrowHR(pFactory->CreateDecoderFromFilename(
			pszFile, NULL, GENERIC_READ, WICDecodeMetadataCacheOnDemand, &m_pDecoder));

		// Validate the given frame index nFrame
		UINT nCount = 0;
		// Get the number of frames in this image
		if (SUCCEEDED(m_pDecoder->GetFrameCount(&nCount)))
		{
			if (nFrame >= nCount)
				nFrame = nCount - 1; // If the requested frame number is too big, default to the last frame
		}
		// Retrieve the requested frame of the image from the decoder
		IfFailedThrowHR(m_pDecoder->GetFrame(nFrame, &m_pFrame));

		// Retrieve the image dimensions
		IfFailedThrowHR(m_pFrame->GetSize(&m_nWidth, &m_nHeight));

		// Convert the format of the image frame to 32bppBGR
		IfFailedThrowHR(pFactory->CreateFormatConverter(&m_pConvertedFrame));
		IfFailedThrowHR(m_pConvertedFrame->Initialize(
				m_pFrame,                        // Source frame to convert
				GUID_WICPixelFormat32bppBGR,     // The desired pixel format
				WICBitmapDitherTypeNone,         // The desired dither pattern
				NULL,                            // The desired palette
				0.f,                             // The desired alpha threshold
				WICBitmapPaletteTypeCustom       // Palette translation type
				));
	}
	catch (...)
	{
		// Cleanup after something went wrong
		Cleanup();
		// Rethrow the exception, so the client code can handle it
		throw;
	}
}

The above code shows the basics of loading an image. To learn more about the different parameters to the different COM calls, consult the MSDN. Here are a couple of MSDN links to make it easy to find the right pages:

• IWICImagingFactory
• IWICImagingFactory::CreateDecoderFromFilename()
• IWICBitmapDecoder
• IWICBitmapDecoder::GetFrameCount()
• IWICBitmapDecoder::GetFrame()
• IWICBitmapFrameDecode
• IWICBitmapSource::GetSize()
• IWICImagingFactory::CreateFormatConverter()
• IWICFormatConverter
• IWICFormatConverter::Initialize()

The CNuonImg::IsLoaded(), CNuonImg::GetWidth(), and CNuonImg::GetHeigh() methods are simple one-liners.

bool CNuonImg::IsLoaded() const
{
	return m_pConvertedFrame != nullptr;
}

UINT CNuonImg::GetWidth() const
{
	return m_nWidth;
}

UINT CNuonImg::GetHeight() const
{
	return m_nHeight;
}

The CNuonImg::Render() method is responsible for rendering the image to the given HDC.

#define DIB_WIDTHBYTES(bits) ((((bits) + 31)>>5)<<2)

void CNuonImg::Render(HDC hDC, UINT x, UINT y, UINT cx, UINT cy)
{
	// Make sure an image has been loaded
	if (!IsLoaded())
		throw WINCODEC_ERR_WRONGSTATE;

	// Get the WIC factory from the singleton wrapper class
	IWICImagingFactory* pFactory = CWICImagingFactory::GetInstance().GetFactory();
	if (!pFactory)
		throw WINCODEC_ERR_NOTINITIALIZED;

	// Create a WIC image scaler to scale the image to the requested size
	CComPtr<IWICBitmapScaler> pScaler = nullptr;
	IfFailedThrowHR(pFactory->CreateBitmapScaler(&pScaler));
	IfFailedThrowHR(pScaler->Initialize(m_pConvertedFrame, cx, cy, WICBitmapInterpolationModeFant));

	// Render the image to a GDI device context
	HBITMAP hDIBBitmap = NULL;
	try
	{
		// Get a DC for the full screen
		HDC hdcScreen = GetDC(NULL);
		if (!hdcScreen)
			throw 1;

		BITMAPINFO bminfo;
		ZeroMemory(&bminfo, sizeof(bminfo));
		bminfo.bmiHeader.biSize         = sizeof(BITMAPINFOHEADER);
		bminfo.bmiHeader.biWidth        = cx;
		bminfo.bmiHeader.biHeight       = -(LONG)cy;
		bminfo.bmiHeader.biPlanes       = 1;
		bminfo.bmiHeader.biBitCount     = 32;
		bminfo.bmiHeader.biCompression  = BI_RGB;		

		void* pvImageBits = nullptr;	// Freed with DeleteObject(hDIBBitmap)
		hDIBBitmap = CreateDIBSection(hdcScreen, &bminfo, DIB_RGB_COLORS, &pvImageBits, NULL, 0);
		if (!hDIBBitmap)
			throw 2;

		ReleaseDC(NULL, hdcScreen);

		// Calculate the number of bytes in 1 scanline
		UINT nStride = DIB_WIDTHBYTES(cx * 32);
		// Calculate the total size of the image
		UINT nImage = nStride * cy;
		// Copy the pixels to the DIB section
		IfFailedThrowHR(pScaler->CopyPixels(nullptr, nStride, nImage, reinterpret_cast<BYTE*>(pvImageBits)));

		// Copy the bitmap to the target device context
		::SetDIBitsToDevice(hDC, x, y, cx, cy, 0, 0, 0, cy, pvImageBits, &bminfo, DIB_RGB_COLORS);

		DeleteObject(hDIBBitmap);
	}
	catch (...)
	{
		if (hDIBBitmap)
			DeleteObject(hDIBBitmap);
		// Rethrow the exception, so the client code can handle it
		throw;
	}
}

Here are some links to the MSDN documentation to learn more about the different parameters to the functions used in the above piece of code.

• IWICBitmapScaler
• IWICImagingFactory::CreateBitmapScaler()
• IWICBitmapScaler::Initialize()
• CreateDIBSection()
• IWICBitmapSource::CopyPixels()
• SetDIBitsToDevice()

Now you can start using the class to load and render images. The basic flow for rendering an image to a device context (hDC) at position (0,0) with given width and height is as follows:

try
{
	CNuonImg img;
	wchar_t* filename = L"C:\\Users\\Public\\Pictures\\Sample Pictures\\Tulips.jpg";
	img.Open(filename);
	img.Render(hDC, 0, 0, width, height);
}
catch (HRESULT hr)
{
	// Handle error
}

Click here to download a small MFC demo application that uses the above class to load an image.

That’s it for this first introduction to WIC. If you have suggestions for topics for future posts about WIC, let me know in the comments below.

C++, one of the most popular programming languages used in everything from Web browsers to 3D video games, has been fully updated and published as, ISO/IEC 14882:2011, Information technology – Programming languages – C++.

ISO/IEC 14882:2011 defines the programming language and specifies requirements for implementation. Also known as C++11, this is the first major revision of the standard since 1998. Its new features extend C++’s traditional strengths of flexibility and efficiency – for example, lambda functions, move semantics, and variadic templates further enable developers to use powerful expressiveness and strong abstraction to write efficient, high-performance code with full access to the hardware available when needed. Even more, the new C++11 has the convenience and ease of use of other modern languages – from features like auto type deduction and explicit virtual override control, to standard smart pointers that mean never writing delete again.

You can read the complete press release here.

• The image loading code is not as robust as I would like it to be. It’s error prone, and crashes on certain files. To resolve this issue, I will throw away all current image loading code and rewrite it all. The result should be more robust, more resilient to corrupt image files, and more flexible. It will also support new image formats, but I don’t know yet exactly which formats. If you have image files that cause Wallpaper Cycler to crash, you can always send them to me.
• The current WCL file format often gives problems. These problems are especially noticable with big wallpaper lists (> 10.000 wallpapers). Because of the issues with the file format, Wallpaper Cycler sometimes corrupts the WCL. To resolve this issue, I will throw away all WCL saving and loading code and replace it with a completely new file format. Just as with the image loading rewrite, the result will be more robust, more flexible, and hopefully more performant.
• Too complex/confusing UI. Wallpaper Cycler has a lot of features. Unfortunately, the result is that the user interface is not always easy to use. Some people simply get lost in the user interface. To start resolving this issue, I’m thinking of replacing the toolbars with a modern, context-sensitive, ribbon bar. I’m also thinking of including an option to choose between a Basic UI and an Advanced UI. In the Basic UI, certain less used option are not shown or burried deeper away, as to prevent them from cluttering up the UI.
• The layout editor is often cause of frustration. The current layout editor has a number of usability issues. I don’t have any concrete solutions yet, but I need to find some solutions to try to make it much more user friendly, at least for basic layouts.

The motherboard is an ASRock H67M-GE/HT:

The PSU is a “be quiet Dark Power Pro PSU”. It’s very quiet

The first thing I assembled into the case was of course the power supply:

This case has several ways to mount the harddrives. You can mount them using elastic bands, or you can mount them on rubber feet. I chose the rubber feet.

Next, unboxing and installation of the Intel i7 2600k CPU

The 16 GB Corsair Vengeance memory looks pretty nice

Next up is the little speed daemon, the Intel 510 SSD:

And lastly, the graphics card, a Gigabyte AMD Radeon HD 6850. I chose AMD over NVidia for this machine, because I want more than just dual-monitor, and as far as I know, NVidia cards only support dual-monitor. Note that the card has two very big fans on it. However, since these fans are soo big, they can rotate slower than small fans, which greatly reduces the noise made by this graphics card

And finally some views of the fully assembled PC, which also shows the LG Blu-ray burner at the top:

All components have been selected with noise in mind. I wanted a silent PC, and I must say that I’m very satisfied. Sometimes, I really have to listen carefully to hear if the PC is running or not, so I succeeded in my goal of a silent PC

• Intel i7-2600k
• 16 GB Corsair Vengeance memory
• Intel 510 SSD (120GB)
• 2 x 2TB WD RE4 drives in mirroring RAID
• be quiet Dark Power Pro PSU (really quiet PSU)
• Antec Solo (a rather silent case, including some sound damping materials)
• triple monitors

I must say, it’s very very fast, especially thanks to the SSD. The 16GB RAM come in handy for running virtual machines
Once you’ve worked on a system with an SSD as system drive, you simply don’t want to go back to using mechanical drives as system drive…

The developer preview also includes a preview of Microsoft Visual Studio 11 express edition, which makes it very easy to make Metro style applications in C++, C#, VB.Net, or JavaScript.

Any serious developer should download this preview and learn as much as possible about the new Windows platform.

Go to the BUILD website to download the preview and to download interesting video recordings of the sessions on the BUILD conference.