Update: I added a few stations and changed the registration to use the /allusers switch (so this will show up on Media Center Extender) so pay attention to the setup instructions below.

Coding Friday resulted in a little Windows Media Center Presentation Layer Web Application called Veronicas Radio, named after a Program Manager on the Windows Media Center team who came to me one day and said 'hey, it would be cool if I could have all of my favorite streaming radio stations in a customized UI, just for me'. At least I remember the conversation going something like that. Anywho...

I took the helix we did for the Q app (see http://play.mediacentersandbox.com/mcml/rc1/helix.mcml for the codeless version) and added a call to PlayMedia to create a streaming radio URI. After applying a Gaussian blur to one of the sample pictures which ship with Windows to represent a background (nice pink) and station images (culled / created from their respective websites) we now have something that looks like this in Windows Media Center...

You can install this web app to your Diamond RC1 machine as follows:

1. Download http://play.mediacentersandbox.com/mcml/rc1/setup.veronicasradio.zip
2. Unzip the contents to your local machine.
3. Open a command prompt with Administrator priviledges.
4. Run setup.veronicasradio.cmd.
5. Launch Windows Media Center and Select ‘Veronicas Radio’ in Program Library.

We think it would be pretty cool to see what other mods or hacks folks could do with the helix. Hit this URL with IE > View Source: http://play.mediacentersandbox.com/mcml/rc1/veronicasradio.mcml, modify to your liking, post to your own web server, post an installer (everything you need is in the install download for Veronicas Radio) and let's see what neat mashups you can create.

Charlie

I have been working on some Windows Media Center application debugging and deployment scenarios recently so that we can enhance some of the documentation in the Windows Media Center SDK for Windows Vista.  I want to document one of the interesting configurations here in case it is useful in your Windows Media Center application development scenarios.

Before I get started, I want to note that the steps listed below work equally well if you are developing in Visual C# 2005 Express Edition or Visual Studio 2005 Standard or higher.  For simplicity's sake, I will refer to both by the single name "Visual Studio" in the instructions below.

Step 1: Getting started

I started by installing Windows Vista RC1 (Ultimate Edition), Visual C# 2005 Express Edition and the Windows Media Center SDK for Windows Vista RC1.  Then, I created a Visual C# Windows Media Center Presentation Layer (WMCPL) application in Visual C# Express.

By default, the WMCPL application is configured to launch the standalone version of McmlPad and navigate to the file default.mcml that is a part of the project.  The steps below allow you to configure the WMCPL project so that it will register the application with Windows Media Center and automatically launch the Windows Media Center shell and navigate to the application when pressing F5 to build and debug in Visual Studio.  The steps require you to make some modifications directly to the .csproj file, and then make some modifications to the project settings in the Visual Studio IDE.

Step 2: Modify settings in the .csproj file

Open the .csproj file for your WMCPL application project (located at c:\Users\<username>\Documents\Visual Studio 2005\Projects\<solution name>\<project name> by default) in a text editor such as notepad and make the following changes:

1. Override the pre-build target so that Visual Studio will ignore pre-build event errors using the technique described in this blog post.  You can do this by adding the following section to the bottom of the  .csproj file just before the closing </Project> tag:
   
     <Target Name="PreBuildEvent" Condition="'$(PreBuildEvent)'!=''" DependsOnTargets="$(PreBuildEventDependsOn)">
       <Exec WorkingDirectory="$(OutDir)" Command="$(PreBuildEvent)" IgnoreExitCode="true" />
     </Target>
   
2. Change the <StartProgram> to be $(windir)\eHome\ehshell.exe (replacing the default value of $(windir)\eHome\McmlPad.exe)
3. Change the <StartArguments> to be /entrypoint:{<app_guid>}\{<entrypoint_guid>} /addinfallbackpath:"$(FullyQualifiedOutputPath)" (where <app_guid> and <entrypoint_guid> are the GUIDs listed in the App.xml file that is generated when you create a new Windows Media Center Presentation Layer Application)
4. Save the changes and close the .csproj file

Step 3: Update project settings in the Visual Studio IDE

After modifying and saving the WMCPL application .csproj file using the steps listed above, open it in Visual Studio and perform the following steps:

1. Right-click on the project in Solution Explorer and choose Properties
2. Click on the Build Events tab in the Property Pages
3. Add the following text to the Pre-build event command line text box: %windir%\eHome\RegisterMceApp.exe /u App.xml
4. Add the following text to the end of the Post-build event command line text box (make sure to leave the command line there that appears by default to run mcmlverifier.exe to validate the MCML syntax in your project): %windir%\eHome\RegisterMceApp.exe App.xml
5. Click on the File menu and choose Save All to save the updated project settings

Once you have completed all of the above steps, you can press F5 in the Visual Studio IDE to build and run the WMCPL application, and it will launch Windows Media Center and navigate directly to the application by using the /entrypoint command line switch that is available for ehShell.exe.

I have found these steps useful when I want to rapidly preview a WMCPL application hosted within Windows Media Center because I do not need to manually register the application and add the application assembly to the global assembly cache (GAC) each time I rebuild it.  Note that you will want to eventually add a strong-name key to your assembly, create an installer for your application (using a technique such as this) and install the assembly to the GAC for real-world deployment scenarios.

Unfortunately, you cannot use Visual Studio to debug the application code if you directly launch it in Windows Media Center using the above steps.  Visual Studio attaches to the process that it launches (which in this case is the Windows Media Center shell application - ehShell.exe).  Each application hosted in Windows Media Center is then launched in a new instance of the Windows Media Center hosting application - ehExtHost.exe.  That ehExtHost process is the one that you need to attach to in order to debug the application code.  You can, however, use steps like the ones documented in this previous blog post to attach and debug application code within ehExtHost.exe.

Hopefully you will find this technique useful in some of your Windows Media Center application development scenarios.

Aaron

Hi, I'm Peter Dampier a Program Manager in the eHome division at Microsoft. Many thanks to Aaron and Charlie for this blog and the opportunity to post here.  One of the new features in Windows Vista Media Center post Beta 2 is extensibility for adding HD DVD and/or Blu-ray Disc movie playback to Windows Media Center in Vista.   I thought I'd spend a few moments here to explain this functionality...

There are two main features: 

1. The ability to launch a third party playback application when a HD DVD or BD disc is inserted into the drive and MCE is full screen.  If MCE is not full screen then the regular 2’ Windows auto play is used.
2. The ability to launch a third party application if a HD DVD or BD disc is in the optical drive and “Play DVD’ is selected from the MCE start menu

 To register your HD DVD or BD playback app there are two new categories for application registration:

 AutoPlay\HD DVD

 And

 AutoPlay\Blu-ray

Two examples are below.  These will register Notepad.exe to launch when MCE is full screen and a HD DVD is inserted and for Calc.exe to launch when a Blu-ray Disc is inserted.  These could also be regular native MCE applications (e.g. HTML/ActveX, MCML or XBAP).  For external .exe's the application developer will need to ensure that they restore MCE to its previous postion after the .exe closes.  A demonstration of how this can be done is available with the MCE games that ship in Vista (check out MCE's Program Library Game content).  Without this the user will be left in a state where they need to reach for the mouse or keyboard after finishing HD DVD playback in the external application versus automatically being returned to MCE. 

To use these samples save the XML below to c:\notepad.xml and c:\calc.xml.  Then register the apps with:

C:\Windows\ehome\RegisterMCEApp.exe /allusers c:\notepad.xml

C:\Windows\ehome\RegisterMCEApp.exe /allusers c:\calc.xml

To un-register:

C:\Windows\ehome\RegisterMCEApp.exe /u /allusers c:\notepad.xml

C:\Windows\ehome\RegisterMCEApp.exe /u /allusers c:\calc.xml

For the applications to show up in the regular MCE Program library they will also need to be registered against other categories with a separate registration.

XML for HD DVD – Launch notepad.exe:

 <application title="Notepad" id="{ABCE8379-F381-47b8-AE3D-EF6ADE750500}" companyname="Sample Company" companylogourl="http://company/icon2.jpg" description="HD DVD App">

    <entrypoint id="{ABCE8379-F381-47b8-AE3D-EF6ADE750501}" RUN="c:\windows\notepad.exe" title="Notepad (Sample HDDVD App)" description="Notepad - a text editor">

        <category category="AutoPlay\HD DVD"/>

    </entrypoint>

</application>

XML for Blu-ray Disc – Launch calc.exe

<application title="Notepad" id="{2C5ECB67-E585-4301-BAF4-5380FE6C26AB}" companyname="Sample Company" companylogourl=" http://company/icon2.jpg" description="BD App">

    <entrypoint id="{2C5ECB67-E585-4301-BAF4-5380FE6C26AB}" RUN="c:\windows\System32\Calc.exe" title="Calculator (Sample Blu-Ray App)" description="Calculator application ">

        <category category="AutoPlay\Blu-ray"/>

    </entrypoint>

</application>

If more than one application is registered against each category then the user is presented with a page to select the playback app they wish to use.

If no applications are registered the following dialogs appear:

Peter.

I have been working on some debugging topics that will hopefully eventually be included in the Windows Media Center SDK for Windows Vista, and I wanted to put some of these topics together and create an end-to-end scenario demonstrating how you can use Visual Studio 2005 to debug your Windows Media Center application code as it is running within Windows Media Center.

Please note that these instructions require Visual Studio 2005 Professional Edition or higher because the lower editions of Visual Studio 2005 (such as the Express Editions) do not include a debugger that allows you to attach to running processes.

As I wrote this blog post, I tried out these steps with the Q podcast and video blog client sample application that is included in the Windows Media Center SDK.  However, the same set of steps can be used for any Windows Media Center application that includes an add-in assembly.

Step 1 - Build and install the Windows Media Center application

The first step to start debugging your application is to compile your code in Visual Studio 2005, install the resultant assembly to the GAC, and use RegisterMceApp.exe or RegisterApplication to register the application so that it can be launched from within Windows Media Center.

Step 2 - Enable Windows Media Center add-in launch debugging

Set the following registry value on your system to cause a Windows Media Center dialog to appear when attempting to launch any add-in. The dialog will display the process name and process ID that you can use to attach a debugger, set breakpoints, and step through the code in your add-in that is executed when Windows Media Center attempts to load and run it.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Settings\Extensibility]
EnableAddInLaunchDebugging = 1 (REG_DWORD)

Step 3 - Launch Windows Media Center and click on the entry point to start your add-in

After setting the EnableAddInLaunchDebugging registry value, launch Windows Media Center and click on the entry point for your application.  When doing this, a dialog box like the following will appear and you can use it to attach a debugger:

Step 4 - Attach to the ehexthost process in Visual Studio 2005

After launching your application in Windows Media Cener, leave the Debug Application dialog open and launch Visual Studio 2005 Professional or higher.  Click on the Tools menu and choose Attach to Process...  A dialog like the following will appear:

This dialog lists all running processes on your system.  Locate the process name and process ID that is listed in the Debug Application dialog in Windows Media Center, click on it to highlight it and then click the Attach button to cause the Visual Studio debugger to attach to the process.

Note that if Visual Studio 2005 was already running when you clicked on your Windows Media Center application, you may need to click the Refresh button in the Attach to Process dialog before the process you are looking for appears in the list.

Step 5 - Configure symbol settings for the add-in assembly in Visual Studio 2005

Now that you have attached to the process, you need to configure symbol settings so that you can set breakpoints and debug your add-in assembly code.  Open the Modules window in Visual Studio by pressing Ctrl + Alt + U or by going to the Debug menu, choosing Windows and then choosing Modules.

When the Modules window appears, locate the DLL that represents your add-in assembly, right-click on it and choose Symbol Settings...  A dialog like the following will appear:

Use the new folder icon to add a symbol file (.pdb) location.  Provide the full path to the \bin\<flavor> directory for the built binary for your add-in assembly.  Make sure to choose the correct <flavor> (either debug or release) depending on which flavor of the add-in assembly is currently running in Windows Media Center.  After adding the symbol file location, make sure that the check box next to the symbol path is checked and then click OK to dismiss the symbol settings Options dialog.

You can verify that you chose the correct symbol location by looking in the Module window and verifying that the Symbol Status for your add-in assembly now says Symbols Loaded.

Step 6 - Configure Visual Studio option to allow setting breakpoints in managed code

Go to the Tools menu in Visual Studio 2005 and choose Options...  Expand the Debugging item in the options tree and select General.  Verify that the option named Enable Just My Code (Managed only) is checked.  Click OK to dismiss the options dialog.

Step 7 - Set breakpoints and start debugging

Now you are ready to set some breakpoints in your source code and start debugging.  Open up your source code files in the Visual Studio IDE and click on the line numbers you are interested in debugging to set breakpoints.  After you have set all of the breakpoints you want, click OK on the Debug Application dialog in Windows Media Center to resume execution of your application.  You should see breakpoints hit if you set them in the correct places, and you can use the Visual Studio debugger to step through your code.

Step 8 - Repeat as necessary

If you need to start a new debugging session, you can start again at step 3 of the above instructions.  The process ID in the Debug Application dialog will change each time you launch your application, so you will need to make sure to attach to the new instance of ehexthost.exe in Visual Studio 2005.

Hopefully these steps will be useful to you as you develop your Windows Media Center applications in Windows Vista.

Aaron

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

As many of you have probably noticed, it can be tricky to debug problems that occur while loading and running an add-in assembly hosted within Windows Media Center.  Fortunately, there are 2 fixes in post-beta 2 builds of Windows Vista that make Windows Media Center add-in debugging a little easier.

Enabling the Details button for the add-in crash dialog

The first debugging fix we have added is a registry value that will add a Details button to the error dialog that appears when a Windows Media Center add-in crashes.  The registry value is located at:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Settings\Extensibility]
EnableErrorDetails = 1 (REG_DWORD)

The Windows Media Center SDK for Windows Vista sets this value automatically starting with the 5456.5 build that is available on the Microsoft Connect site for Windows Vista beta program members, and you can also set it manually on a Windows Vista OS that contains Windows Media Center to gain the same functionality.

When you have this registry value set, you will see a dialog that looks like the following when an add-in crashes:

The Details button only appears if the registry value is set.  The rest of the dialog will look the same regardless of whether or not you have the registry value set.

When you click on the Details button, Windows Media Center will display the callstack that caused the crash.  It will look something like this:

Unfortunately, because of the way that Windows Media Center add-ins are hosted in an external process (ehexthost.exe) and how some of the exceptions thrown by Windows Media Center are wrapped and bubbled back up, the callstack may not always be particularly useful.  However, there are many cases where this has already proven useful to our development team while trying to track down add-in crashes.

Enabling a dialog to allow you to attach a debugger

The second debugging fix we have added is a registry value that will cause a Windows Media Center dialog to appear when attempting to launch any add-in.  The dialog will display the process name and process ID that you can use to attach a debugger, set breakpoints, and step through the code that is called in your add-in when Windows Media Center attempts to load and run it.  The registry value is located at:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Media Center\Settings\Extensibility]
EnableAddInLaunchDebugging = 1 (REG_DWORD)

When you have this registry value set, you will see a dialog that looks like the following when attempting to launch any add-in within Windows Media Center:

While this dialog is on-screen, you can attach your debugger of choice to the specified process name/ID and then press OK to resume the Windows Media Center add-in launch process.

Unlike the previous registry value, the Windows Media Center SDK does not automatically set this value because it noticeably interferes with the ordinary usage of Windows Media Center in non-development scenarios.  You will have to set this registry value yourself to gain this functionality.

Hopefully these new registry tweaks will be useful to you as you develop and debug your Windows Media Center add-ins.

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