The Windows Media Center Platform Team Blog RSS 2.0
 Sunday, March 26, 2006

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

Categories: Resources | Comments [5] | # | Posted on Sunday, March 26, 2006 3:10:20 AM (GMT Standard Time, UTC+00:00)   
Friday, March 31, 2006 1:57:39 AM (GMT Standard Time, UTC+00:00)
Thanks for the article - Im looking forward to reading the rest...

Some MCML related questions for the Sandbox crew :

1) I can't get MCML Sampler (from Feb CTP SDK) to operate on 5342 (worked fine on 5308). I can install the .msi fine - but when I launch it via MCE | More Programs - it gives me an 'Invalid Application' error. Is this a known issue - or is there something Im not doing right? (Please dont tell me I need to reinstall 5308)

2) As per above - is the HelloMCML sample in the SDK expected to work on build 5308?.

3) Is there some more updated docs for MCML coming soon? (whats there is a great start - but missing some vital parts of the puzzle in some areas).

4) As per above - the big point of confusion for me with MCML is how the layout/co-ordinates systems work (the rest seems to make sense)..

For example the FormLayoutInput Tag has attribute values for the Top/Left/Right with strange syntax such as 'Parent,0' and 'Parent,0,150' ...

It seems similar to WinFX but with more twists? Can you guys provide some more explanation of what the extra values are (ie are they relative cordinates to the 'Parent' as a fraction of 1, z-order specifications ?)


Thanks - and hope this is the right place to ask these questions..


Sunday, April 02, 2006 9:54:13 AM (GMT Standard Time, UTC+00:00)
Hi Niall, thanks for the questions.

1 & 2: The 5308 SDK tools and samples are matched to build 5308. They won't work on 5342. Build 5342 was a CTP 'refresh' build of the OS. I'm not sure if a matching SDK refresh was produced but I'll ask around.

3: Absolutely! We've been working hard on the SDK since 5308. Look for more documentation, samples and tool updates soon.

4: Wow, big question. I'll see if I can shed some light on the concepts you mentioned...

At the page level within Media Center, the coordinate system is based on a 1024x768 logical display. A scale is automatically applied so that a UI authored to this space fits the actual screen resolution. Aspect ratio handling is a little more complex, but the principle is the same.

Within an individual MCML UI, the coordinate system is an abstract set of logical units whose usage depends on the context where it is used. For example, if a UI is hosted within a parent that maniputates scale, the coordinate system is effectively controlled by that parent.

FormLayoutInput allows you to specify an anchor point for an edge of the object you are laying out. For example, you might be anchoring the bottom of an image to the top of another object.

The first value is the object name to anchor to. It can be any named object in your UI, plus pre-defined names like 'Parent' and 'Focus'.

The second value specifies the anchor point on the referenced object. A value of 0 represents the 'near' edge (left/top), while a value of 1 represents the 'far' edge (right/bottom). Thus, .5 would be 'center' and 1.1 would be "10% beyond the far edge."

The third value is an optional constant offset, in UI coordinates.

Thus, your example 'Parent,0,150' in the context of a 'Top' or 'Bottom' anchor would mean "150 units below the top edge of the parent."

The same input for a 'Left' or 'Right' anchor would mean "150 units right from the left edge of the parent."

I hope this helps clear up the areas you're interested in. Thanks for trying out MCML!

Francis
Francis Hogle
Monday, April 10, 2006 5:20:58 PM (GMT Standard Time, UTC+00:00)
Interesting stuff.
I really like the fact that I'll be able to code these swish animated controls without learning to code in directx. But a couple of criticisms:

1. too much chat and not enough demo

2. edit! or at least work out that camera position.

3. show me 10' control demos, not buttons with mouse rollovers, my MC doesnt have a mouse

4. stop the BS about "No code". Seriously I keep hearing:
"And it's all markup"
"Really, all markup?"
"Yes all markup, zero code".

Then we see the markup. Hey it looks like code.
Hard to work with code, too: all angle brackets and indents.

People, markup is code. It's not really prettier than C# against a nice API either. It's uglier in fact.

That mcml file you showed is several hundred lines of highly-indented, difficult-to-read CODE, that I won't be able to put a breakpoint in anywhere.


Otherwise, nice job. Look forward to playing with it. Hey I don't mind markup that much. Just don't tell me it ain't code.
rhubarb
Tuesday, April 11, 2006 12:56:36 AM (GMT Standard Time, UTC+00:00)
Hi Rhubarb,

--> Too much chat and not enough demo.

I *totally* agree -- I kept trying to vector Robert to the demo (I said a couple of times something like 'that's what we want to show you in Marks demo' and pointing over to Mark. He kept coming back to me asking questions about remote controls, XBox 360, etc. I didn't want to be totally rude. :-)

--> edit! or at least work out that camera position.

Talk to Robert -- the whole ethos of Channel9 is low budget, single cheap camcorder. It largely works, but can result in motion sickness at times.

--> Show me 10' control demos, not buttons with mouse rollovers, my MC doesnt have a mouse.

Agreed, and Mark actually had that in his script -- we just ran out of time. We began to see this with 'ctl:Button' in the MCML. Note we aren't shipping any controls which look and feel like Windows Media Center -- but you can create ones on par with us.

UI created for use in Media Center should work equally well for mouse, keyboard and remote control, which is why the MCML Preview Tool shows you when the mouse focus occurs (as it does for keyboard). In order to see that in action during the demo we would have needed two buttons on screen. As it was, we only had a single button, and its focus indicator was green as expected.

Also note 'ctl:Button' isn't a control in the traditional sense you might be thinking -- it was user created MCML, not a control which ships as part of our platform. The usage could just as easily have been 'charlieswonderfulcontrols:AwesomeButton'.

--> stop the BS about "No code".

Yeah, we've been working on this messaging and agreen haven't quite gotten it right. I don't mean to imply it's easy by saying 'only markup, no code'. In fact, I call this out during the interview by saying you need to be an 'angle bracket code monkey' (in other words, an XML guru) to do anything useful in MCML.

The important thing here is 'zero code' gives us the ability to do things like deliver MCML over the web and have it do beautiful (from a design perspective -- you don't need any code to accomplish gorgeous animations) and meaningful (from a 'you can play a video in Media Center using markup only') things without burdening or endangering the user with C# code on the local machine. XML can't do any harm to the users computer -- a badly written C# app can. It also opens the door to zero-install scenarios.

--> That mcml file you showed is several hundred lines of highly-indented, difficult-to-read CODE...

Once you learn MCML it's not as hard to read as you think. :-) The Alphabet Soup example Mark shows currently stands at 198 lines, 52 of which define the upper and lower case letters of the alphabet (net of 146 lines of 'code'). This file on my hard disk takes up 8K. Show me an example of any other sort of markup, code or markup + code which does what is demonstrated in the video with as few total lines or size. Heck, it might even be doable -- sounds like a fun challenge. :-)

--> ...that I won't be able to put a breakpoint in anywhere.

Hmmmm, I'll have to ponder this, but you are right in you can't breakpoint (at least not currently). MCML is usable or it's not from the parsers perspective (binary) and it's certainly not linear like C# code, making this feature largely useless. We will have debugging services available from within markup though, to help you with things for which you would traditionally use a breakpoint, and the MCML Preview Tool gives you accurate and specific line numbers where there are problems with the MCML.
Tuesday, April 11, 2006 1:01:38 AM (GMT Standard Time, UTC+00:00)
For my last comment / reply back to Rhubarb: he was referring to the latest Channel9 video located at http://channel9.msdn.com/Showpost.aspx?postid=180410.
Comments are closed.
Blogroll
About

Disclaimer
All information available via this site is provided 'as is' with no warranties and confers no rights.

© Copyright 2008 Microsoft Corporation.

Sign In
All Content © 2008, Microsoft Corporation.