Charles Petzold this month launches his new DirectX Factor column, which will explore the opportunities developers have in Windows 8 to write fast, native code for both traditional client and mobile/tablet form factors. I caught up with Charles and asked him about his plans with the new column.
Michael Desmond: Your new column is called DirectX Factor. Why DirectX? Why now?
Charles Petzold: The short answer is: Windows 8.
For almost a decade now, I’ve been coding for various .NET platforms using C# and XAML, so when Microsoft unveiled Windows 8, of course it was great to see a XAML-based framework in the Windows 8 API. At the same time, I was quite intrigued to see support of C++, not as a managed language but to generate native code, and moreover, to see an extensive DirectX API that can be accessed only from C++.
Well, of course, it all makes sense. This is Windows, and we want to be able to write high-performance code for Windows. We want an option to use a language that’s been designed to generate fast native code, and we want the option of targeting an API that’s been designed for high-performance utilization of video and sound hardware.
Windows 8 gives us these options, and this is essential: As Windows runs on smaller and less hefty processors on tablets and other mobile devices, and as we strive to make the user interfaces of our Windows applications become faster and more fluid, C++ and DirectX have become more important than ever. This is what I’d like to explore in this column.
Desmond: So should we be looking to move away from managed platforms and languages?
Petzold: No, no, no, not at all. But we need to choose our languages and platforms intelligently. For many applications, XAML in combination with a managed language is fine. But if you need high-performance graphics, or text, or sound, don’t kid yourself thinking that C# and XAML represent the peak of efficiency. Get serious.
Sure it would be great to use one universal language and platform. But programming is not some abstract mathematical exercise. This is the real world, and we need to be very alert to performance issues. We need to know when managed code is fine, and when native code is essential.
Desmond: You’ve been focused on Windows Phone and mobile/touch development for a couple years. How does the new column impact that focus? Will we still see Windows Phone coverage here?
Petzold: Windows 8 actually highlights a problem with Windows Phone 7. The Windows Phone 7 API supports managed code only, with two application platforms. If you can’t get your XAML-based Windows Phone 7 program to run fast enough, you can try rewriting it for XNA, but with XNA you’re still using a managed language and you’re still going through a managed API. And if you can’t get your Windows Phone 7 XNA program to fun fast enough, you’re stuck. You’ve hit the wall.
The Windows Phone 8 API corrects this deficiency in the same way as Windows 8 — by supporting native C++ code and DirectX. Naturally that provokes the question: What’s involved in developing DirectX code that can run on both Windows 8 and Windows Phone 8 hardware? That’s something I’d definitely like to explore in this column.
Desmond: What topics can readers expect the DirectX Factor column to address in the near future?
Petzold: I’ve decided to begin exploring DirectX under Windows 8 with the sound-generation component, which has the rather unsexy name XAudio2. But within a few months I expect to get into 3D graphics. As we developers work with more intimate touch-based user interfaces, I am particularly interested in how we can use touch to manipulate complex graphical objects. I actually think this is one of the keys to giving rather bulky fingers more precision on the screen.
All the sample programs I’ll be describing in DirectX Factor will combine DirectX with a XAML-based user interface. That’s something we really haven’t been able to do before, and I’m thrilled to have the opportunity to write about these techniques.