The day after the geek dinner Scott Hanselman and I sat down to chat about developing for Windows Media Center for Hanselminutes 82. The result is a pretty nice introduction to what you need for development, the tools included in the SDK, some of the samples which are included in the SDK and some basic beginner concepts. Here is a detailed list of links which corresponds to the various topics we covered during the podcast.

Enjoy...!

2:15 Software Development Kit http://www.microsoft.com/downloads/details.aspx?familyid=a43ea0b7-b85f-4612-aa08-3bf128c5873e&displaylang=en
2:29 Visual C# 2005 Express Edition http://msdn2.microsoft.com/en-us/express/aa975050.aspx
2:38 Media Center Markup Language http://msdn2.microsoft.com/en-us/library/bb189823.aspx
3:40 MCML Preview Tool http://msdn2.microsoft.com/en-us/library/bb189325.aspx
6:30 Z Sample Application http://blog.mediacentersandbox.com/IntroducingTheZSampleApplication.aspx
11:46 Remoting of the User Interface http://blog.mediacentersandbox.com/AQuickPeekUnderTheHoodPartOneOfFour.aspx and http://blog.mediacentersandbox.com/AQuickPeekUnderTheHoodPartTwoOfFour.aspx (we never got around to parts 3 and 4 -- they would have been much deeper than we really needed to go).
12:15 Remote Control and Input Handlers http://msdn2.microsoft.com/en-us/library/bb189195.aspx
18:08 Managed Code Object Model http://msdn2.microsoft.com/en-us/library/ms816271.aspx
19:00 Application Types Which Leverage MCML: Local and Web http://msdn2.microsoft.com/en-us/library/ms816272.aspx
21:00 Installation and Registration of Applications http://msdn2.microsoft.com/en-us/library/ms815407.aspx
23:10 Q Sample Application (Screenshot) http://play.mediacentersandbox.com/sample/5/q/screencap.png
24:14 MCML Sampler (Screenshot) http://play.mediacentersandbox.com/sample/5/mcmlsampler/screencap.png
25:01 Databinding in MCML http://msdn2.microsoft.com/en-us/library/bb188939.aspx
26:28 Defining a <UI> http://msdn2.microsoft.com/en-us/library/bb189704.aspx
27:37 <UI> Properties http://msdn2.microsoft.com/en-us/library/bb189635.aspx
28:04 Media Center Sandbox http://blog.mediacentersandbox.com
28:30 Visual Studio 2008 'Orcas' Templates from Aaron Stebner http://blogs.msdn.com/astebner/archive/2007/09/11/4873223.aspx
28:45 Using the Visual Studio Templates http://msdn2.microsoft.com/en-us/library/bb189732.aspx

Update: I'm adding a mini-FAQ at the bottom as the comments and feedback arrives.

As part of the documentation updates for the upcoming revision of our Windows Media Center Software Development Kit I have been writing some topics on how to effectively use the MCML Preview Tool (MCMLPad.exe) during development. Since I've seen a few blog posts and discussion forums on the topic I thought I would preview this documentation for you, and ask for feedback and / or additional areas which need coverage. So, try this on for size...

Editing UI
The MCML Preview Tool is designed to assist in the development of individual pieces of UI and as such is specifically designed to NOT scale the MCML content you view therein when run in standalone mode. When run in Windows Media Center the MCML Preview Tool inherits the proportional scaling applied to all applications which run within Windows Media Center. There are some good reasons for this, among which my favorite is the the authoring and preview cycle when creating pieces of UI. You want to see your UI at full size, especially if working on some very nuanced / small feature of that UI. Because Windows Media Center scales the content proportionally to the window, the visual elements can get quite small when you want to switch quickly between your MCML authoring environment and the MCML Preview Tool. Compare the size of the button in each of the windows to the right of IDE window in this screenshot:

The MCML Preview Tool running in Windows Media Center is on the top and the standalone version is on the bottom (note: you can click on most of the images in this post for a life size view). As you can see, when editing the styling of the UI you want to be working at 100% -- otherwise it's just too small when you are fine tuning.

Evaluating Layout and Behavior
When run standalone, the MCML Preview Tool gives you the ability to see how your layout works and looks given different sizes and aspect ratios. Windows Media Center runs with two main aspect ratios in mind: 16:9 and 4:3. You can always set the monitor to some other resolution (example: 1920x1200 for 16:10) and run Windows Media Center at full screen to get different aspect ratios -- but this is rather tedious to do during development of the UI pieces. By contrast, you can run MCMLPad with a completely arbitrary size. For example, here I am testing the snowflake virtualization sample gallery at a 4:1 aspect ratio:

As I increase the overall size, the gallery grows to accomodate more rows and columns of data, and I can observe how it handles this scenario (including and Show or Hide animations). This is without having to change the panel which defines the 'gallery' holding the snowflakes in my application, and avoiding recompiling, installing to the GAC and registering in Windows Media Center as I edit. Here is the result -- note the item sizes don't change because there is no proportional scaling -- we simply see more snowflakes:

Page Variables
The MCML Preview Tool has a page concept, but it is distinctly different (and much more simple) than the one provided by Windows Media Center (the PageSession and HistoryOrientedPageSession classes). Granted, a 'page' is really <UI Name=Page> -- but the underlying functionality for what you expect a page to do within the overall platform is provided by Windows Media Center. A good way to think about this: The MCML Preview Tool is designed to work with the visual layer of the platform only. Once you get far enough along to test page behaviors it's time to switch over to testing the pieces / parts of the application with Windows Media Center as the host rather than the MCML Preview Tool. An even better approach is to test the page behavior very early in the application development cycle using wireframe resources. The simple button from MCML Sampler is a great example of UI to use to implement and test the layout and databinding which involves your page variables. Later on you replace Simple Button with the more beautiful, fully realized design.

Testing UI
When run standalone, the MCML Preview Tool allows you the flexibility to create a test harness for your UI. To demonstrate, I have created a simple test harness (download the sample solution here) for a button. Here is a screen shot:

Windows Media Center (top right) has the application (a compiled assembly) running which loads Menu.mcml allowing me to test the functionality of the button -- in this case, it makes a method call to display a Windows Media Center dialog. The standalone MCML Preview Tool window (bottom right) is the result of pressing F5 in Visual Studio which loads Test.mcml, designed to show all the different ways to instantiate the button using it's settable properties (again, the non-scaling is quite desireable here).

Taking this a large step further: Throughout the creation and testing of the Z sample application we used the power of layouts and rules in MCML to provide a mechanism to step through all of the the UI for Z. Here is what it looks like:

On the right we have each UI which defines an individual page within the Z sample application. You can select these items to load that 'page' (again, it's really a <UI> which, when combined with the HistoryOrientedPageSession becomes a bonified page in the application) into the larger, 4:3 constrained area on the left. This test harness is defined by Default.mcml in the sample code which ships in the SDK if you wish to adapt for use in your own applications.

To gain the Visual Studio F5 test harness functionality with the Z sample solution...

If you haven't previously done so...

• Launch a command prompt with administrator privileges.
• Navigate to C:\Program Files\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Z\.
• Run Command.CreateDevEnvironment.cmd.

...otherwise MCMLPad will report an exception and close when you use F5 in Microsoft Visual C# 2005 Express Edition because the Z test harness can't find the data.

Then make the following changes in Microsoft Visual C# 2005 Express Edition:

• Select Solution 'Z' (2 Projects) in Solution Explorer.
• Select Project > Set StarUp Projects... from the menu.
• Select Startup Project in the Solution 'Z' Property Pages.
• Select the Single Startup Project option.
• Select 'Z' in the drop down list.
• Click OK.

Finally, select Debug > Start Debugging or press the F5 key to launch the Z test harness.

Note we set everything up to work this way by default for you in the Visual Studio template which ships with the SDK. Here are the basics of how this works if you want to modify to fit your workflow:

In order to launch MCMLPad from within Microsoft Visual C# 2005 Express Edition you have to manually edit the .csproj file for the solution because the Start Action setting isn't available in the Express SKUs user interface -- but it still works if you add some XML. For the purposes of this example let's take a look at the snippet which provides this functionality from the Z.csproj file:

  <PropertyGroup>
    <UseVSHostingProcess>true</UseVSHostingProcess>
    <StartWorkingDirectory>$(windir)\eHome</StartWorkingDirectory>
    <StartArguments>-load:"resx://Z/Z.Resources/Default" -assemblyredirect:"$(FullyQualifiedOutputPath)" -markupredirect:"resx://Z/Z.Resources/,file://$(MSBuildProjectDirectory)\Markup\,.mcml"</StartArguments>
    <StartAction>Program</StartAction>
    <StartProgram>$(windir)\eHome\McmlPad.exe</StartProgram>
  </PropertyGroup>

Most of these should be self explanatory and I'll break down <StartArguments> for you as it's the most complex but most important (read the Media Center Markup Language Preview Tool SDK topic for more information)

-load:"resx://Z/Z.Resources/Default"

Tells MCMLPad to load the Z assembly and navigate to the resource named Default (which is Default.mcml) contained therein. Default.mcml is never used by the application once installed -- its only purpose is to provide this <UI> test harness.

-assemblyredirect:"$(FullyQualifiedOutputPath)"

Tells MCMLPad to load the assembly from a specific location. When $(FullyQualifiedOutputPath) is evaulated it returns something like this: C:\Program Files\Microsoft SDKs\Windows Media Center\v5.0\Samples\Windows Media Center Presentation Layer Samples\Z\bin\Debug\. Note this won't work if the assembly is registered to the Global Assembly Cache, so be mindful of when you run Command.InstallAndRegister.cmd contained in the sample solution.

-markupredirect:"resx://Z/Z.Resources/,
 file://$(MSBuildProjectDirectory)\Markup\,
 .mcml"

This one is broke up into its three constituent parts on different lines for ease of readability. This tells the MCML Preview Tool to replace instances of 'resx://...' with 'file://...' and append .mcml to the end. This allows you to build the assembly once, load the test harness (Default.mcml) into the tool, make changes to the source MCML and test the results of those changes by refreshing MCMLPad without having to rebuild the assembly -- what I call interactive editing.

Interactive Editing
You can also create a compiled assembly and open MCML files directly in the MCML Preview Tool using the same -load, -assemblyredirect and -markupredirect switches as in the Visual Studio .csproj file. This allows you to edit / tweak UI and avoid recompiling, installing to the GAC and registering in Windows Media Center as noted earlier. You can use the command line for this, or the MCML Preview Tool Launcher power toy. Using this approach you can edit and preview your changes in real time by refreshing the MCML Preview Tool after you make markup changes. For example:

In this screenshot we see the power toy defining the proper switches for the MCML Preview Tool, and the launched MCML Preview Tool window with our markup loaded. I've edited the Styles.mcml resource to change the focused button text color to red. I can continue to tweak all of Button.mcml resources (anything referenced with xmlns in the opened markup file, including those downstream) and returning to the MCML Preview Tool and pressing the F5 key to refresh and see my changes without a need to recompile. This allows me to make as many changes as I wish to the UI without committing them to my compiled assembly.

There are also other ways to leverage the power of the MCML Preview Tool -- with a little experimentation  -- so dig in...!

Mini-FAQ

How do I get proportional scaling in the MCML Preview Tool?
Use <ScaleLayout MaintainAspectRatio="true" AllowScaleUp="true" AllowScaleDown="true"/> in your test harness. For an example look at Default.mcml in the Z sample application, specifically <UI Name="TestWrapper">.

How can I easily switch between 16:9 and 4:3 aspect ratios?
The MCML Preview Tool defaults to 4:3 aspect ratio. Select the top or bottom window frame, hold down the CTRL key and size the window up or down -- the window will eventually 'snap' to the 16:9 aspect ratio. To reverse, select the right or left window frame, hold down the CTRL key and size the window up or down.

How can I test pieces of UI which are wired up to Windows Media Center APIs?
Generally speaking, you shouldn't (or rather, wouldn't). If the individual <UI> pieces are hard coded like this you probably aren't architecting your application properly -- even in a web / codeless scenario. In a properly architected application you should almost *always* be able to test your individual pieces of <UI> in the MCML Preview Tool without hooking them up to the Windows Media Center API. Follow the example in Button.mcml provided in the sample code for this post. When you run the application in Windows Media Center it loads Menu.mcml which uses the <Command> model item and <Rules> to wire up the functionality (in this case a C# method). When you are designing or testing the visuals for Button.mcml you load Test.mcml in the MCML Preview Tool. Test.mcml contains several <Command> model items but no <Rules> to perform the binding -- therefore the buttons behave visually as they will in the application, but have no functionality.

Jossef Goldberg (a program manager on the Windows Presentation Foundation team who focuses on integrating WPF with Windows Media Center) sent me a list of newsgroups and forums that he has found useful for customers who have questions related to developing XBAPs for Windows Media Center for Windows Vista:

• Windows Presentation Foundation (WPF) developer portal
• Windows Presentation Foundation (WPF) MSDN Forum
• Sample XBAP controls for Windows Media Center
• XBAP forum on the Media Center Sandbox site

Hopefully these resources will be helpful if you are working on XBAP solutions for Windows Media Center for Windows Vista.

Aaron

A Look at Media Center's Rendering Engine

In Part One, we examined the high-level architecture of the Windows Media Center Presentation Layer, including the relationship between its User Experience Framework and Rendering Engine.  In this installment, we’ll take a more detailed look at the Rendering Engine and its component parts.

The Rendering Engine is an internal component of Media Center.  It is designed to be used exclusively via the Windows Media Center Presentation Layer’s Messaging System and requires a sophisticated client such as the User Experience Framework to drive it.  It is written in C++ and places extreme emphasis on simplicity and performance.

To understand how the Rendering Engine works, we need to start by examining its foundation and work upward.

Underpinnings

The lowest layers of the Rendering Engine aren’t directly concerned with media processing tasks at all.

The Rendering Engine’s Core Services form a foundation runtime for all rendering features.

• The Scheduling layer is a simple work-queue system for handling incoming requests to the Rendering Engine.  It also contains custom logic for integrating time-critical periodic work that bypasses normal queue processing.
• The Memory Management layer provides heap support optimized to the Rendering Engine’s threading and allocation patterns.
• The Message Transport layer implements an endpoint of the Messaging System.  Pluggable transport implementations allow for flexibility in how the User Experience Framework and Rendering Engine are connected and deployed.
• The Object Management layer defines an object-oriented model for presenting Rendering Engine functionality to Messaging System clients.  It provides identity and lifetime management services and includes facilities for resource partitioning and graceful cleanup of per-application resources.

Now that we’ve seen the foundation, we can start to look at layers where rendering actually happens.

Output Options

Pluggable Output Drivers allow for audio-visual rendering on a variety of technologies and hardware platforms.

Output Drivers do the “heavy lifting” to implement rendering functionality by providing peer implementations for many of the key objects in the Presentation Model.  Current drivers include DirectX, Win32 and XBOX 360 implementations for graphics and sound.

Various driver implementations have existed in Media Center over the years.  In addition to the obvious physical platform support (set-top boxes, PCs, game consoles), output drivers have been used to provide flexibility in the development process.  For example, Windows XP Media Center Edition 2004 (a.k.a. Harmony) was based on DirectX 7.  For Windows XP Media Center Edition 2005 (a.k.a. Symphony), we moved to DirectX 9 and significantly reworked some of our graphics algorithms.  To keep this work from disrupting other parts of the project, we supported both the D3D7 and D3D9 graphics output drivers side-by-side for most of the project.

At startup time, the User Experience Framework communicates directly with Output Drivers in order to initialize and configure the Rendering Engine.  Once things are up and running however, the conversation moves up a layer in the stack.

Painting a Picture

The Rendering Engine’s abstract Presentation Model defines building blocks that can be combined to create an audio-visual scene.

Once the Rendering Engine has been initialized, the User Experience Framework describes UI scenes using objects from the abstract Presentation Model.

• A Graphics Device exposes properties, capabilities and rendering configuration of a graphics technology (e.g. GDI, D3D…)
• A Render Operation implements an individual unit of work to be performed during a rendering pass.  It can also track possible cleanup or error handling that may be required later in the pass.
• A Visual defines a unique coordinate space in the rendering hierarchy.  Visuals are organized as a tree and expose UI-relevant states like transforms and constant alpha.  These states are translated into rendering operations as needed during a rendering pass.  Visuals may also contain rendering operations for drawing content as directed by the User Experience Framework.
• A Clip Gradient is a hybrid primitive that performs color channel modulation according to a specified ramp, optionally clipping.  It permutes the output of other render operations.  A variety of visual effects are possible.  The most visible example is the “edge fade” effect used when scrolling lists and galleries in Media Center.
• A Surface is a drawable piece of pixel-mapped visual data (like an image or video frame).
• A Surface Pool is physical storage for one or more surfaces.  On technologies where texture allocation is expensive enough to cause glitches, a Surface Pool may be sub-allocated to hold multiple Surfaces.  For video playback, a Surface Pool may hold multiple frames of video data.
• A Sound Device exposes properties, capabilities and rendering configuration of an audio technology (e.g. Win32, DSound, XAudio…)
• A Sound Buffer is physical storage for audio data.
• A Sound is a logical instance of playback from a Sound Buffer.

With these features, the User Experience Framework can compose a static scene and send it coarse updates.  This is enough to produce UI that looks like Media Center, but not yet enough to build UI that feels like Media Center.  For that, we need animation.

A Measure of Independence

An important goal of separating the Rendering Engine from the User Experience Framework is to allow for loosely-coupled timing between them.  From a rendering perspective, a continuous stream of new frames needs to get to the screen without involving the User Experience Framework very often.

In addition to creating or modifying states via the Presentation Model, the User Experience Framework can direct the Animation System to modify presentation states on a frame-by-frame basis according to a timeline.  Any numeric property in the presentation model (single or composite) can be animated.  Many effects are orchestrated from the User Experience Framework by creating a scene and adding animation to it.

• The Value Table is a set of individual values being computed for animation purposes.
• A Sequence is a keyframe-based timeline for modifying an individual value in the Value Table.
• An Interpolation is a function that can be applied to produce intermediate values between two keyframes in a sequence.  Examples include Linear, Sine, Square, Bezier, etc.
• A Property Connector collects one or more values from the Value Table and combines them to update an object property.  Also supports sampling from the target property to initialize keyframes before a sequence is played.

The Animation System also has a special callback registered with the scheduling layer for monitoring the passage of scene time.  This allows various output driver implementations to synchronize animation updates with other media processing.  For example, the DirectX driver for both PC and XBOX may prepare frames in advance based on upcoming presentation timestamps from a video stream.

Renderer Wrap-Up

It is easy to see why the Rendering Engine requires a sophisticated client to drive it.  The design includes few graphical primitives and follows a strict philosophy of keeping complexity out of the rendering path.  Complex scenes are achieved by composing many simple elements together.  Orchestration of interactive UI scenes and transitions is a task left to the User Experience Framework, the topic of our next installment.

Francis

The goal of this series is to provide some technical background for Media Center application authors who are interested in what the Windows Media Center Presentation Layer is and how it works.

This post takes an introductory look at the Windows Media Center Presentation Layer’s internal components and architecture.  Future posts will provide additional detail on the topics discussed here.  Some implementation detail has been simplified so we can focus squarely on the functionality authors can use from MCML.

Architecture
The Windows Media Center Presentation Layer has three distinct architectural components: a User Experience Framework and a portable Rendering Engine with an asynchronous Messaging System connecting them.

Each component has a different role.  The User Experience Framework makes complex 10-foot UI problems tractable and easy.  The Rendering Engine delivers composited UI and video at high and stable frame rates.  The Messaging System decouples the operation of the other two components with a high-performance, queued-command interconnect.

This configuration provides several important benefits:

• It allows the User Experience Framework to employ computationally expensive UI algorithms without compromising the performance of the rendering path.
• It allows the User Experience Framework and Rendering Engine to run in different security contexts if needed.
• It allows the User Experience Framework and Rendering Engine to be on different physical devices without sacrificing UI interactivity or fidelity.
• It allows the Rendering Engine to be shared by multiple client processes and gracefully tolerate client failures.
• It allows the Rendering Engine to employ custom, media-oriented timing algorithms that would otherwise burden UI code with unusual constraints.

The Messaging System doesn’t have a lot of internal complexity.  For the rest of this discussion, we’ll dig a little deeper into the designs of the User Experience Framework and Rendering Engine.  As we will see, both components are highly modular, allowing for (and owing to) rapid evolution over short product cycles.

Here’s a modified diagram that highlights the major architectural features of the User Experience Framework and Rendering Engine:

As the User Experience Framework and Rendering Engine have different design goals, they also have substantially different internal architectures.  Where the User Experience Framework focuses on high-functionality and configurability, the Rendering Engine implements narrow set of functionality with an extreme emphasis on efficiency.  The User Experience Framework is 100% managed code based on the Microsoft .Net Framework.  Its primary external programming model is declarative XML.  In contrast, the Rendering Engine is 100% unmanaged code whose primary programming model is an optimized binary command stream.

Here’s a summary of the components in the diagram above:

User Experience Framework

• Common Primitives - Defines a library of useful objects for MCML authors (images, text, video, list handling…).  Exposes rendering features and advanced UI customization support from the libraries.
• MCML UI Description Model - Ties together underlying UI and rendering services to provide the core MCML authoring model.
• UI Library - Implements a variety of modular UI services (layout, input, data binding, web resource fetching…).
• Rendering Library - Provides a low level programming model for communicating with and controlling the Rendering Engine.
• Core Services - Implements core UI interoperability and scheduling models to facilitate modular design and integration of framework components.

Rendering Engine

• Animation System - Provides facilities for describing modifications to the Presentation Model according to a timeline.  Allows the Rendering Engine to modify UI scenes on a per-frame basis without looping in the User Experience Framework on each clock tick.
• Presentation Model - Defines an abstract model for describing a scene (visuals, transforms, sounds…).
• Output Drivers - Provides technology-specific implementations of the Presentation Model (DirectX, XBOX, Win32/GDI…).
• Core Services - Forms the foundation for Rendering Engine features and communication with the User Experience Framework.  Implements memory management, an unmanaged object system, a scheduling layer and a transport endpoint for the Messaging System. 

It’s interesting to note that only the top two layers of the User Experience Framework (MCML UI Description Model and Common Primitives) are exposed as public API surface.  The rest of the layers are just how we bring the functionality to you while leaving room to grow in the future.

The other day I commented in our Windows Media Center Presentation Layer Web Applications intro post that this post would provide answers about how MCML-based applications can get native fidelity on XBOX 360 while their markup and code run on the Media Center PC.  The answer should be clear at this point: we’ve ported the Rendering Engine and its end of the Messaging System to XBOX 360.

This concludes our architectural introduction to the Windows Media Center Presentation Layer.  I hope this post helps situate MCML in your mind and provides some context for what’s going on under the markup.

Francis

I've been learning more about how Windows Media Center Presentation Layer Applications are run on the XBox 360 Media Center Extender. For a while now I've been stating these apps render at 30 Frames Per Second (FPS). As the Hertz commercial says, well...'not exactly'.

But unlike the Hertz commercial, this 'not exactly' is a good thing.

As Paul Harvey would say, here is the rest of the story...

For a Windows Media Center Presentation Layer Application, the Windows Media Center Rendering Engine running on the XBox 360 combines the video signal (deinterlacing when necessary) with the user interface and renders both to match the current frame rate of the display. On the XBox 360 in the United States that means you get a refresh rate of 60 Hz or Frames Per Second. (It's worth noting the XBox 360 native refresh rate can be different depending on the geography.) Generally speaking, the higher the refresh rate, the smoother the experience appears to the user and less noticeable flicker.

By contrast, the Hosted HTML or Hosted WinFX XBAP Application user interfaces are rendered on the Media Center PC with 3-5 screenshots taken per second (on average) which are sent over the network via a Remote Desktop-like pipe. Even though the XBox 360 display output is much higher these applications will appear to operate at a much lower framerate due to the rate at which screenshots are sent.

So, why have I been saying '30 FPS' for the last couple of months? It's what I knew from my work with the Windows Media Encoder (NTSC television is shot at 30 FPS and output to your TV at 60 Hz, film is shot at 24 FPS and typically projected at 72 FPS using the shutter to avoid flicker) and was the best way I could describe at the time how the three types of applications will appear to the end user. My apologies to our readers for not getting the facts 100% straight before posting / answering questions. In this case I hope you will say 'no harm, no foul'.

If you want to learn more about refresh rates, head on over to Wikipedia at http://en.wikipedia.org/wiki/Frame_rate.

Francis Hogle (Development Manager for the Windows Media Center team) is preparing a four part series which explains how this stuff works in greater detail -- look for it here soon.

Charlie